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