re: the periodic rescan was the freeze driver; first trustworthy negative

Two changes this iteration, one failed and reverted, one that worked.

Trimming the witness calibration to eight spread 512 KB windows instead of the
full region found 17 candidates, none of them frame counters, and the witness
then reported 0 of 17 stalled on every sample of a run that recorded 13 losses.
That is a total contradiction, caught by the same internal check that exposed
the previous three witness failures. The frame-rate cluster is sparse and spread
sampling misses it. Reverted: two 32 MB reads once at startup is simply the
price of a witness that works.

The recurring cost was the periodic rescan, a 32 MB read every 90 to 180
seconds, and it exists only to catch craft appearing from nowhere -- which the
roster work already established does not happen, since every participant is
allocated at mission load and an arrival is a state change rather than an
allocation. Disabled.

The result is the first fully clean probed run: 3875 candidates, 32 witnesses at
11/s, no stall flag on any sample from t=0 to t=210, and eight losses spread
across it. Previous probed runs froze at 27, 45, 83, 183 and 255 seconds. This
one ended on the turn timeout. One run, so not proven, but together with the
clean no-probe control it points at recurring heavy reads rather than at memory
reading as such.

That also produces the first arrival result that means what it says. Every
earlier one carried a caveat -- a stalled guest, an unvalidated witness, a probe
degrading what it measured. This one has a validated witness reporting no
stalls, a demonstrably live guest, and a clean end: zero confirmed arrivals over
210 s of verified-live Stage 02 flight, roughly 115 game-seconds, while the
player destroyed eight craft.

It does not settle the question. The route table's t = 170, 210 and 240 entries
remain out of reach in a single turn. But it does establish that nothing arrives
in the first ~115 game-seconds of phase 1 under those conditions, which none of
the previous fifteen runs could honestly claim.

docs/re/guest-stalls.md

@@ -338,3 +338,41 @@ 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.
+
+---
+
+# ✅ The periodic rescan was the freeze driver (2026-08-24)
+
+Two changes, one failed and reverted, one that worked.
+
+## 🔴 Trimming the calibration broke the witness
+
+Sampling 8 spread 512 KB windows instead of the full region found **17**
+candidates, none of them frame counters, and the witness then reported
+`0/17 stalled` on **every sample of a run that recorded 13 losses** — a total
+contradiction, caught by the same internal check as the previous three failures.
+The frame-rate cluster is sparse and spread sampling misses it. Reverted.
+
+Two 32 MB reads *once at startup* is the price of a witness that works.
+
+## ✅ Disabling the periodic rescan removes the freeze
+
+The recurring cost was the rescan — a 32 MB read every 90–180 s — and it exists
+only to catch craft appearing from nowhere, which the roster work already showed
+does not happen: every participant is allocated at mission load, so an arrival is
+a state change on an existing craft, not a new allocation. Disabled.
+
+Result, the first fully clean probed run:
+
+```
+tick witnesses: 3875 candidates, using 32 at 11/s (frame-rate band)
+t=  0s … t=210s   no stall flag on any sample
+8 losses recorded across the run
+```
+
+**Zero stalls over 210 s**, against freeze onsets of 27, 45, 83, 183 and 255 s in
+every previous probed run. n = 1, so this is not proven — but combined with the
+clean no-probe control it points clearly at recurring heavy reads rather than at
+memory reading as such.
+
+The run ended on the turn's timeout, not a freeze.