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/guest-stalls.md

@@ -296,3 +296,45 @@ 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.
+
+---
+
+# ✅ The witness is validated (2026-08-24, fourth attempt)
+
+```
+tick witnesses: 6500 candidates, using 32 at 21/s (frame-rate band)
+t= 15s down=0
+t= 30s down=1                       <- loss, NOT flagged
+t= 45s down=0  *** GUEST STALLED (0/32 witnesses moved) ***
+t= 60s … t=211s  down=0  *** GUEST STALLED (0/32) ***   (every sample)
+TOTAL down=1  stalled samples=12
+```
+
+**Zero contradictions.** The single loss falls in an unflagged sample; every
+flagged sample has no losses. That is the internal-consistency check the three
+previous versions each failed, and it passes here.
+
+What made the difference was searching the **whole 32 MB region** rather than a
+4 MB window — 6500 candidates instead of 5, with a clean cluster at 21 /s
+matching the measured frame rate.
+
+## 🔴 But the freeze is now clearly the dominant problem
+
+Onset across runs: **27, 45, 83, 183, 255 s** — median around 83 s. This run
+froze at 45 s and produced exactly one loss, so it is useless for the arrival
+question even though the instrument finally works.
+
+The usable window is one to four minutes and unpredictable. Fourteen of fifteen
+runs have gone into the arrival question and it still has no answer, largely
+because of this.
+
+## The probe is still not cheap
+
+Worth being honest about: "cheap probe" was never that cheap, and the witness
+made it worse. It still reads 32 MB to enumerate at startup, another 32 MB every
+90 s to rescan, and the full-region calibration added **two more 32 MB reads**.
+The freeze at 45 s came immediately after that calibration.
+
+Trimmed: calibration now samples **8 spread windows of 512 KB** (4 MB total,
+still covering the whole span) rather than reading everything twice, and the
+rescan interval is doubled to 180 s. Not yet run.