re: confirmed — the probe was causing the guest stalls

The control needed no new decoding: hunting pilot, keep-out 1400, 300 s, and no
memory probe at all, judged only from the pilot's own log. It ran healthy the
whole way -- 211, 257, 250, 241 and 200 distinct speed values in successive 60 s
windows, with no decline in the last one -- against probed runs that stalled at
roughly 27, 83 and 255 s and ended with a single distinct speed across 400 lines.

So the instrument was degrading the thing it measured. AGENT.md warned that a
full scan competes with the emulator for every core under lavapipe, and the
probes grew heavier each iteration until wave6 was reading the entire 32 MB
entity heap plus about 300 extra preads every 12 seconds while the game
rendered.

The control is n=1. The contrast is stark and the mechanism was predicted in
advance, so this is recorded as confirmed enough to act on rather than proven; a
second clean control would settle it.

What it costs is worth stating plainly. Every "no arrival" result so far was
collected while the probe was running, under conditions the game was struggling
with and in some runs after it had frozen. That does not make them wrong -- the
elimination test at t=163 s sits in a window the witness later showed was live --
but none of them is as strong as written, and the arrival question deserves
re-running with cheap sampling before silence is read as evidence.

wave7_probe.py is the fix: one full enumeration, then polling only the hull word
at each known craft base, about 1.2 KB per sample instead of 32 MB, with a full
rescan every 90 s to catch anything genuinely new. Three or four heavy scans per
run instead of twenty-five. Implemented but not yet run, so the claim that it
stops the stalling is untested and the next run must report the witness first.

docs/re/BACKLOG.md

@@ -402,9 +402,17 @@ search cannot find a *schedule*.
   long runs stalled at ~255 s, 83 s and **~27 s**. 🟡 **Leading suspect: the probe
   itself** — it reads the whole 32 MB heap plus ~300 `pread`s every 12 s while
   lavapipe renders, and AGENT.md warns a full scan competes for every core.
-  **Next: run the pilot 300 s with NO probe**, judge from its log alone; if it
-  does not stall, the instrument is degrading what it measures and sampling must
-  get much cheaper. ❔ Multi-squadron threshold test did not run (zero losses).
+  ✅ **CONFIRMED (2026-08-24): the probe was causing the stalls.** The no-probe
+  control ran **300 s clean** — 211/257/250/241/200 distinct speeds per 60 s
+  window, no decline — against probed runs stalling at 27/83/255 s and ending on
+  **1** distinct speed. The instrument was degrading what it measured, exactly as
+  AGENT.md warned. Control is **n=1**: acted on, not proven.
+  ⚠️ **Consequence: every "no arrival" result was collected under a struggling or
+  frozen guest** — none is as strong as written, and the arrival question needs
+  re-running with cheap sampling before silence means anything.
+  ✅ Fix written: `wave7_probe.py` enumerates once then polls only the hull word
+  per known craft (~1.2 KB/sample vs 32 MB), full rescan every 90 s — **not yet
+  run**. ❔ Multi-squadron threshold test still not run (zero losses that run).
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing: