docs(ci-reds): R7 seventh occurrence, and four hypotheses excluded

The next gate run of the same worktree reproduced R7 immediately --- same
selector, same three fragments --- and that run's other seven stages were
green, sweep included and complete, so the pair is not confounded by the
truncation that marred the sixth.

Two consecutive in-gate failures is new for a row whose prior five were
spread across lanes and months, so it prompted a narrowing. Seventeen
green runs at the failing head on the failing worktree exclude four
hypotheses: the selector being flaky (3 isolated), the gpu binary's own
concurrency (6 full runs), the gate's isolated TMPDIR (6 runs under a
gate-shaped 61-character path, tested because this project already knows
socket-path length matters), and residue from the m4 stage the gate runs
immediately before gpu (2 back-to-back pairs).

So the discriminator is inside scripts/gate versus outside it, and it is
not the TMPDIR, not the preceding stage, and not the binary's
concurrency. The row does not guess at what remains --- the gate's
ambient root, its exported environment, and process state carried across
stage boundaries are named as uneliminated, not as suspects.

Causal status stays UNRESOLVED, but the question is sharper than it was:
previous entries compared trees and lanes, and this one locates the
difference in the runner.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai

docs/active-work.md

@@ -321,6 +321,14 @@ from #171 and #215.
   selector green three times, and **this lane touches no `pmacs-gpu`
   file at all** — its whole diff is two `assert!` message strings and
   two docs.
+- **GATE RUN 2: 7/8, `gpu` red on R7 again** (head `45d438c`, log
+  `20260829T150011Z-429115`). `sweep` ran fully green this time.
+  **Two consecutive in-gate R7 failures prompted a narrowing**: 17 green
+  runs outside the gate excluded the selector being flaky, the gpu
+  binary's own concurrency, the gate's TMPDIR, and residue from the
+  preceding `m4` stage. The discriminator is in-gate versus out, and
+  the three obvious runner differences are ruled out. Recorded in the
+  registry; **not this lane's to solve**.
 - **Still owed, separately:** `workflow_dispatch` on `ci.yml`, and U9's
   discriminating control — pin test-binary concurrency to 1, then load
   a lone `--lib` binary — which has been named since 2026-08-09 and

docs/ci-red-signatures.md

@@ -526,10 +526,42 @@ at `pmacs-gpu/src/attach.rs:1889`, `283 passed; 1 failed`.
   `07-sweep.log` ends in `Terminated`. That stage's absence says
   nothing, and the run as a whole is **not** a gate result. Only the
   `gpu` stage's failure is, because it completed and reported.
-* **Causal status: still UNRESOLVED**, and this occurrence does not
+**A SEVENTH OCCURRENCE FOLLOWED IMMEDIATELY**, on the next gate run of
-  change it. It adds one more data point to "not lane-correlated" — a
+the same worktree at head `45d438c`
-  sixth lane, touching a sixth unrelated surface, seeing the same
+(`20260829T150011Z-429115/06-gpu.log`), same selector, same three
-  three fragments.
+fragments, `283 passed; 1 failed`. **That run's other seven stages were
+green**, `sweep` included and complete — 121 result lines, none with a
+failure — so this pair is not confounded by a truncation the way the
+sixth was.
+
+**Two consecutive in-gate failures is new for this row**, whose prior
+five were spread across lanes and months. It prompted a narrowing, and
+the narrowing is the useful part.
+
+**Four hypotheses EXCLUDED, 17 green runs, all at head `45d438c` on the
+failing worktree:**
+
+| hypothesis | test | result |
+|---|---|---|
+| the selector is simply flaky | isolated selector | **3 green** |
+| the full `-p pmacs-gpu` binary's own concurrency | full binary, outside the gate | **6 green** |
+| the gate's isolated `TMPDIR` (this project already knows socket-path length matters) | full binary under a gate-shaped 61-character `TMPDIR` | **6 green** |
+| residue from `m4`, which the gate runs immediately before `gpu` and which spawns fake LSP servers and PTYs | `m4` then `gpu` back to back, twice | **2 pairs green** |
+
+**So the discriminator is "inside `scripts/gate`" versus "outside it",
+and it is NOT the TMPDIR, NOT the preceding stage, and NOT the
+binary's own concurrency.** Something else about the gate's execution
+context remains, and this row does not guess at it.
+
+**Causal status: still UNRESOLVED.** What these two occurrences add is
+a sharper question than the row had before: previous entries compared
+lanes and trees, and this one says the difference is in the *runner*,
+with the three most obvious runner differences already ruled out.
+
+* **Next occurrence should start from that**, not from another tree
+  exclusion. The remaining candidates are the gate's ambient root, its
+  exported environment, and process state carried across stage
+  boundaries — none of which has been isolated.
 
 **Fifth occurrence — panel cell-mapping generation (§5b) framing,
 2026-08-15, local (Linux).** The `scripts/gate` **`gpu` step** again,