re: persistence rule works; the stall witness gives false positives

Run 12, cheap probe with a bound pilot: 16 losses over 290 s and zero confirmed
arrivals, making twelve runs without one. The persistence rule earned its place
immediately -- an increase of 13 to 15 was surfaced and correctly not counted,
since it does not start from zero. Under the previous rule it would have been
invisible, and a similar flicker straddling zero was nearly written up last
iteration as the first arrival.

The stall witness, on the other hand, is unreliable. Thirteen samples were
flagged GUEST STALLED while recording losses in those same samples, and a frozen
guest cannot destroy craft, so they are false positives and the run was healthy.

The cause is the selection rule: it took the first word in a 4 MB window whose
rate fell in a plausible band, and plenty of counters advance intermittently
without saying anything about whether frames are being rendered. timer_probe had
already solved this properly -- 286 candidates, a rate histogram with a dominant
cluster near 17/s -- and that lesson was not carried over when the witness was
bolted onto the probe.

Now fixed to a majority vote: collect every candidate, keep the modal-rate
cluster, sample up to 32 of them, and report a stall only when fewer than half
advance. It also prints RUN UNVALIDATED when no witness is found, because an
earlier run printed "stalled samples=0" alongside "tick witness: NONE", and a
witness that does not exist cannot report zero stalls. Not yet run.

Consequence worth flagging: the "0 stalled samples" that validated the cheap
probe last iteration came from this same unreliable witness and should be
re-confirmed under the majority rule. The pilot-log speed analysis that
established the stalls in the first place is unaffected.

Also fixed: the entity bind now retries three times and aborts if it never
takes, instead of silently flying an unattended craft -- one run was wasted that
way this iteration, producing no kills and no information.

docs/re/BACKLOG.md

@@ -418,7 +418,21 @@ search cannot find a *schedule*.
   reverted to 0 fifteen seconds later, and the same log shows a record reading 13
   then 14 with no event printed because only decreases were surfaced. Count
   stands at **0 confirmed arrivals in 11 runs**. Probe now prints every increase
-  and requires an arrival to **persist across 2 samples** (not yet run). ❔ Multi-squadron threshold test still not run (zero losses that run).
+  and requires an arrival to **persist across 2 samples**.
+* ✅🔴 **Run 12 (2026-08-24): persistence rule works; stall witness does not.**
+  16 losses / 290 s with a bound pilot, **0 confirmed arrivals** (twelve runs
+  now). One increase surfaced (`13→15`) and correctly not counted — exactly the
+  flicker that nearly became "first arrival". 🔴 **The single-word tick witness
+  gives FALSE POSITIVES**: 13 samples flagged `GUEST STALLED` *while recording
+  losses in the same samples*, which a frozen guest cannot do. Cause: it took the
+  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
+  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).
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing: