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