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/BACKLOG.md

@@ -452,8 +452,19 @@ search cannot find a *schedule*.
   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
+  came right after it. 🔴 **The trim BROKE the witness** (17 candidates, `0/17` on
+  every sample of a run with 13 losses) — reverted; two 32 MB reads once at
+  startup is the price of a working witness. ✅ **Instead, disabling the periodic
+  rescan removed the freeze**: first fully clean probed run, **zero stalls over
+  210 s** with 8 losses, ended by the turn timeout not a freeze (n=1). The rescan
+  existed only to catch newly-allocated craft, which the roster work showed never
+  happens.
+* ✅ **Run 16: the first TRUSTWORTHY negative.** Validated witness, no stall on
+  any sample, guest demonstrably live (8 losses) ⇒ **0 confirmed arrivals over
+  210 s of verified-live flight** ≈115 game-seconds. Establishes that nothing
+  arrives in the first ~115 game-s of Stage 02 phase 1 while the player kills 8
+  craft. Does NOT settle the question — t=170/210/240 route entries are still out
+  of reach. 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

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.

docs/re/mission-arrival-watch.md

@@ -329,3 +329,27 @@ behaviour makes the flicker visible as flicker.
 Caveat on this run: its 13 "stalled" flags are false positives from the
 single-word witness (see [guest-stalls.md](guest-stalls.md)), so the run was
 healthy — but that also means the witness cannot yet certify it.
+
+---
+
+# Run 16: the first trustworthy negative (2026-08-24)
+
+Every previous "no arrival" result carried a caveat — a stalled guest, an
+unvalidated witness, a probe degrading the thing it measured. This one does not:
+
+* the stall witness is validated (zero contradictions with loss data);
+* it reported **no stall on any sample**;
+* the guest was demonstrably live throughout — 8 losses spread across the run;
+* the run ended on the turn timeout, not a freeze.
+
+**Result: 0 confirmed arrivals over 210 s of verified-live Stage 02 flight.**
+
+That is the first observation in this line of work that means what it says. It
+does not settle the question — 210 s of wall-clock is roughly 115 s of game time
+at the measured frame rate, so the route table's t = 170/210/240 entries are
+still out of reach — but it does establish that **nothing arrives in the first
+~115 game-seconds of Stage 02 phase 1 while the player kills eight craft**.
+
+One flicker `up` was surfaced and correctly not counted.
+
+Sixteen runs, still no arrival. The difference is that this one is evidence.