re: the stall witness is validated; the freeze is now the blocker

Fourth attempt at the witness, and it passes the check the previous three
failed. Searching the whole 32 MB region rather than a 4 MB window gives 6500
candidates and 32 witnesses in a clean 21/s cluster matching the measured frame
rate, and the flags have zero contradictions with the loss data: the single loss
falls in an unflagged sample and every flagged sample has none. The guest
genuinely froze at about 45 s and the instrument says so.

That leaves the freeze itself as the dominant problem. Onset across runs is 27,
45, 83, 183 and 255 seconds, median around 83, so the usable window is one to
four minutes and unpredictable. This run produced exactly one loss and is
useless for the arrival question even though the instrument finally works.
Fifteen runs have now gone into that question without an answer, largely for
this reason.

Worth being honest about the probe: "cheap" was never that cheap and the witness
made it worse. It still reads 32 MB to enumerate at startup and another 32 MB
every 90 s to rescan, and the full-region calibration added two more 32 MB
reads. The 45 s freeze came immediately after that calibration. Calibration now
samples eight spread windows of 512 KB -- 4 MB total, still covering the whole
span -- instead of reading everything twice, and the rescan interval is doubled
to 180 s. Not yet run.

Also this iteration: the 42-record anomaly recurred, the discard rule correctly
refused to interpret the run, and a rescan-until-baseline retry is now in place
so the next occurrence shows whether the count climbs toward 116 or sits at 42.

docs/re/BACKLOG.md

@@ -442,7 +442,20 @@ search cannot find a *schedule*.
   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
+  once at startup + warn when <8 witnesses.**
+* ✅ **WITNESS VALIDATED (2026-08-24, 4th attempt)**: full-region search gives
+  6500 candidates → 32 witnesses at 21/s, and the flags have **zero
+  contradictions** with the loss data (the one loss is unflagged; every flagged
+  sample has no losses). That is the check the three previous versions failed.
+* 🔴 **The freeze is now THE blocker.** Onset across runs: **27, 45, 83, 183,
+  255 s** (median ~83 s) — usable window is 1–4 min and unpredictable. This run
+  froze at 45 s with 1 loss, useless for arrivals despite a working instrument.
+  ⚠️ Being honest: the "cheap" probe still reads 32 MB at startup + 32 MB every
+  90 s, and the new calibration added **two more 32 MB reads** — the 45 s freeze
+  came right after it. **Trimmed to 8 spread 512 KB windows + rescan every 180 s
+  — not yet run.** Also: the 42-record anomaly recurred and the discard rule
+  correctly refused the run; a rescan-until-baseline retry is now in place to
+  test whether it climbs. 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