re: fix the bind failure; witness search window was too narrow

Two harness problems, one fixed and verified, one diagnosed.

Bind: three consecutive attempts failed and the session aborted rather than
flying an unattended craft, which is last iteration's guard working as intended.
The cause is that entities2 self finds the player by motion between two samples,
so a craft sitting still at mission start is invisible. The session now holds the
throttle for three seconds before each attempt. Verified: the next run bound
immediately and produced 11 losses with zero confirmed arrivals, making fourteen
runs without one. One increase, 10 to 11, was surfaced and correctly not counted.

Witness: the frame-rate-band selection is still unreliable. It found only five
candidates in band and reported 0 of 5 moved in samples where craft were being
destroyed, and a counter genuinely running at 24/s cannot fail to advance across
a 15 s sample -- it would gain about 360. They are bursty counters that moved
during the 3 s calibration and then stopped.

The cause is mine. When the witness was bolted into wave7_probe the candidate
search was narrowed to a 4 MB window, while timer_probe searched the whole 32 MB
region and found 286 candidates with a clean cluster near 17/s. The narrowing
was never justified, it was just cheaper to write. Now searches the full region
once at startup, which is a one-off cost rather than per sample, and warns
explicitly when fewer than eight witnesses are available so a weak vote is
visible instead of silently trusted. Not yet run.

Worth recording: this is the third attempt at this witness, and all three
failures share one pattern -- a shortcut in selecting the witness rather than in
the voting logic. Each was caught only because the flagged samples contradicted
the loss events in the same output. That internal contradiction is the real
check and should survive into any future version.

docs/re/BACKLOG.md

@@ -436,7 +436,20 @@ search cannot find a *schedule*.
   including samples where craft died: **11/31 advancing is healthy**. Cause: the
   modal cluster was **93/s**, not the ~16.5/s frame rate — bursty subsystem
   counters. **Fixed: prefer the 8–40/s frame-rate band, stall only when ZERO
-  advance — not yet run.** 🔴 **The cheap probe froze too (t≈183 s)**, so the
+  advance.**
+* 🔴 **Witness attempt 3 still unreliable (2026-08-24)**: only **5** candidates
+  in band, and `0/5 moved` in samples where craft died — a real 24/s counter
+  cannot miss 15 s. Cause was mine: the candidate search had been narrowed to
+  **4 MB** when the witness was bolted in, while `timer_probe` searched the full
+  **32 MB** and found 286 with a clean ~17/s cluster. **Fixed: full-region search
+  once at startup + warn when <8 witnesses — not yet run.** All three witness
+  failures share one pattern: a shortcut in *selecting* the witness, each caught
+  only by the flagged samples contradicting losses in the same output.
+* ✅ **Bind failure fixed + abort verified**: `entities2 self` finds the player by
+  MOTION, so a stationary craft at mission start is invisible; the session now
+  holds throttle 3 s before each attempt. One run correctly **aborted** after 3
+  failures rather than flying unattended; the next bound immediately (11 losses,
+  0 confirmed arrivals — 14 runs). 🔴 **The cheap probe froze too (t≈183 s)**, so the
   earlier "0 stalled samples" validation is superseded; with n=1 per arm (control
   clean 300 s, heavy 27–255 s, cheap 183 s) it is unresolved whether cheap
   sampling helps or the freeze is stochastic. ⚠️ **Usable window ≈3 min per run

docs/re/guest-stalls.md

@@ -250,3 +250,49 @@ lucky. Recorded as unresolved rather than resolved in the probe's favour.
 **Consequence:** the usable window per run is roughly 3 minutes, sometimes less,
 whether or not the probe is cheap. Any experiment needing longer than that has to
 survive a freeze or be redesigned around one.
+
+---
+
+# Witness attempt 3: the search window was too narrow (2026-08-24)
+
+Status: 🔴 still unreliable; ✅ cause identified; ✅ bind failure separately
+diagnosed and fixed.
+
+The frame-rate-band selection ran, and still flags stalls in samples where craft
+are being destroyed:
+
+```
+tick witnesses: 96 candidates, using 5 at 24/s (frame-rate band)
+t= 30s down=1 *** GUEST STALLED (0/5 witnesses moved) ***
+t=156s down=1 *** GUEST STALLED (0/5) ***
+t=236s down=1 *** GUEST STALLED (0/5) ***
+TOTAL down=11  stalled samples=7
+```
+
+**Five witnesses is not a vote.** And a counter genuinely running at 24 /s cannot
+fail to advance across a 15 s sample — it would gain ~360. So these are bursty
+counters again: they moved during the 3 s calibration and then stopped.
+
+The cause is mine: when the witness was bolted into `wave7_probe` the candidate
+search was narrowed to a **4 MB** window, while `timer_probe` — which found a
+clean 17 /s cluster — searched the **whole 32 MB** region and found 286
+candidates. Narrowing was never justified; it was just cheaper to write.
+
+**Fixed:** search the full region once at startup (a one-off cost, not per
+sample), and warn explicitly when fewer than 8 witnesses are available so a weak
+vote is visible rather than silently trusted. Not yet run.
+
+This is the third attempt at this witness. The pattern in all three failures is
+the same — a shortcut in *selecting* the witness, not in the voting logic — and
+each was caught only because the flagged samples contradicted the loss events in
+the same output. That internal contradiction is the real check and is worth
+keeping in any future version.
+
+## ✅ Separately: the bind failure is fixed
+
+Three consecutive bind attempts failed and the session **aborted rather than
+flying unattended**, which is the behaviour added last iteration working as
+intended. The cause: `entities2 self` finds the player by *motion* between two
+samples, so a craft sitting still at mission start is invisible. The session now
+holds the throttle for 3 s before each attempt. Verified — the next run bound
+immediately and produced 11 losses.