re: multi-witness vote works, its threshold did not, and freezes persist

The graded output is the improvement. Instead of a single bit it reports how
many witnesses agree, and the sequence tells a coherent story: 11, 9, 7, 4, 1,
then 0 of 31, with the drop to zero at t=183 s coinciding exactly with the last
loss and 106 s of nothing after it. That is a real freeze, identified.

The threshold was wrong though. Flagging a stall at "fewer than half" marked the
entire run stalled, including samples in which craft were destroyed, so 11 of 31
advancing is a healthy guest rather than a stalled one. The cause is the cluster
choice: the modal rate was 93/s, far above the ~16.5/s frame rate timer_probe
measured, and those are subsystem counters that tick in bursts and sit idle in
most 15 s windows even while the game runs. Picking the modal cluster was
convenient rather than principled.

Fixed to prefer the cluster whose rate falls in the frame-rate band of 8-40/s,
falling back to modal only if none exists, and to flag a stall only when zero
witnesses advance, which is the signal the data actually supports. Not yet run.

The uncomfortable part: this run used the cheap probe and still froze, at about
183 s. The previous iteration's "0 stalled samples" came from the unreliable
single-word witness and cannot stand as validation. What the evidence supports
now is that the no-probe control ran 300 s clean, the heavy probe froze at 27 to
255 s, and the cheap probe froze at 183 s -- one run on each arm. Cheap sampling
plausibly helps but does not remove the freeze, and it is equally possible the
freeze is stochastic and the control was lucky. Recorded as unresolved rather
than resolved in the probe's favour.

Practical consequence: the usable window is roughly three minutes per run,
sometimes less, whether or not the probe is cheap. Experiments needing longer
have to survive a freeze or be redesigned around one.

docs/re/BACKLOG.md

@@ -428,8 +428,19 @@ search cannot find a *schedule*.
   first word in a 4 MB window with a plausible rate; intermittent counters pass
   that test. `timer_probe` had already solved this (286 candidates, modal rate
   ~17/s) and the lesson was not carried over. **Fixed to a majority vote over the
-  modal-rate cluster (≤32 witnesses, stall only if <half advance), plus explicit
-  `RUN UNVALIDATED` when no witness exists — not yet run.** ⚠️ The "0 stalled
+  modal-rate cluster, plus explicit `RUN UNVALIDATED` when no witness exists.**
+* ✅🔴 **Run 13 (2026-08-24): the vote is better, the threshold was wrong, and
+  freezes persist.** Graded output (11→9→7→4→1→**0** of 31) is coherent, and the
+  drop to 0/31 at t=183 s coincides exactly with the last loss — a real freeze,
+  106 s of nothing after. 🔴 But "<half = stalled" marked the WHOLE run stalled
+  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
+  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
+  regardless** — design experiments to fit or to survive a freeze. ⚠️ The "0 stalled
   samples" that validated the cheap probe came from the unreliable witness and
   should be re-confirmed. Also fixed: bind now retries 3× and aborts rather than
   flying an unattended craft (one run was wasted that way). ❔ Multi-squadron threshold test still not run (zero losses that run).