docs: bound R7's observation window so the tally stops re-counting itself

The previous commit recorded "in-gate 2 failures in 4 runs" and named
the final verification gate. Re-running the gate on that very commit
made both wrong: a fifth in-gate run, green, and a new log id. Every
docs fix forces a re-gate, and the re-gate invalidates the docs fix.

R7's window is now explicitly the four in-gate runs of 2026-08-29 up to
and including the first green, plus the 17 out-of-gate runs taken
between them. Later verification gates are excluded by definition. A
ratio that grows with review activity measures review activity, not the
phenomenon.

The ledger stops naming the head and log id at all. It records that
every review round ends with a green head-exact gate and points at the
PR body for the current values --- which is the same reason SS5b stopped
recording an ahead-count: a line naming a moving value is stale the
moment it is written, and that lane learned it twice.

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

docs/active-work.md

@@ -330,16 +330,17 @@ from #171 and #215.
   *exclusions* — is corrected there: nothing outside the gate has ever
   reproduced this, so matching one gate condition at a time outside it
   cannot isolate an in-gate cause. In-gate is 2 failures in 4;
-  out-of-gate is 0 in 17 — **and a fourth in-gate run, this lane's
-  final verification gate, was also green, so the cumulative figure is
-  2 in 4**. Recorded in the registry; **not this lane's to solve**.
-- **PR #244** — https://github.com/levineuwirth/pmacs/pull/244, opened
-  at head **`2d76984`**, which is exactly the head the gate ran on.
-- **GATE GREEN, head-exact**: all 8 stages, log
-  `20260829T152824Z-673477`, with `HEAD` and a clean worktree captured
-  before and after. Zero `FAILED` lines and zero non-zero-failure
-  result lines across all eight stage logs, read from them rather than
-  inferred from stage exits.
+  out-of-gate is 0 in 17, over a **bounded observation window** the
+  registry defines so the ratio cannot drift with review activity.
+  Recorded there; **not this lane's to solve**.
+- **PR #244** — https://github.com/levineuwirth/pmacs/pull/244.
+- **Every review round ends with a head-exact 8-stage gate**, green
+  each time, with `HEAD` and a clean worktree captured before and after
+  and the result read from the eight stage logs rather than inferred
+  from stage exits. **The PR body carries the current head and log
+  id**; they are not duplicated here, because a docs commit answering a
+  review moves both, and a ledger line naming them is stale the moment
+  it is written — the lesson §5b learned twice.
 - **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

@@ -561,12 +561,18 @@ isolate an in-gate cause. All these runs establish is that none of the
 four conditions **by itself** reproduces the failure. They do not show
 that any of them is uninvolved when the gate supplies the rest.
 
-**What the observations actually support**, stated at the strength they
-carry: in-gate is **2 failures in 4 runs** — the failing pair, then two
-greens, the second of which is this lane's final head-exact
-verification gate (`20260829T152824Z-673477`) — while out-of-gate is
-**0 failures in 17**. That asymmetry is suggestive and it is not a
-clean split,
+**THE OBSERVATION WINDOW IS BOUNDED, deliberately.** It is the four
+in-gate runs of 2026-08-29 up to and including the first green —
+`20260829T144541Z`, `T150011Z`, `T152024Z`, `T152824Z` — plus the 17
+out-of-gate runs taken between them. **Later head-exact verification
+gates on this lane are NOT part of it and do not move these numbers.**
+Without that boundary the tally re-counts itself every time a review
+round adds a docs commit and the gate is re-run, which is a ratio that
+drifts with review activity rather than with the phenomenon.
+
+**What the window supports**, at the strength it carries: in-gate
+**2 failures in 4**; out-of-gate **0 failures in 17**. That asymmetry
+is suggestive and it is not a clean split,
 because the third in-gate run passed.
 
 **The method for the next occurrence follows from that.** Varying