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:

docs/re/guest-stalls.md

@@ -71,3 +71,57 @@ only the craft bases already located rather than rescanning).
 
 The multi-squadron kill-threshold test did not run: the guest froze before the
 pilot destroyed anything, so there were zero losses and nothing to threshold.
+
+---
+
+# ✅ Confirmed: the probe was causing the stalls (2026-08-24)
+
+The control needed no new decoding — hunting pilot, `SYLPH_KEEPOUT=1400`, 300 s,
+and **no memory probe at all**, judged only from the pilot's own log.
+
+```
+last pilot timestamp: 299.4s
+  t=  0- 60s  distinct speeds: 211
+  t= 60-120s  distinct speeds: 257
+  t=120-180s  distinct speeds: 250
+  t=180-240s  distinct speeds: 241
+  t=240-300s  distinct speeds: 200
+```
+
+Healthy through the entire run, with no decline in the final window. Against the
+probed runs, which stalled at ~255 s, ~83 s and ~27 s and ended with **1** distinct
+speed value across 400 log lines.
+
+**The instrument was degrading the thing it measured.** `AGENT.md` warned about
+exactly this — "the full scan competes with the emulator for every core under
+lavapipe" — and the probes grew heavier each iteration until `wave6_probe` was
+reading the entire 32 MB entity heap plus ~300 extra `pread`s every 12 seconds
+while the game rendered.
+
+**Strength of the claim:** the contrast is stark and the mechanism was predicted
+in advance, but the control is **n = 1**. It is recorded as confirmed-enough to
+act on, not as proven; a second clean control would settle it.
+
+## What this costs
+
+Every "no arrival" result in
+[mission-arrival-watch.md](mission-arrival-watch.md) was collected while the
+probe was running, i.e. under conditions the game was struggling with, and in
+some runs after it had frozen outright. That does not make them wrong — the
+elimination test at t = 163 s happened in a window the witness later showed was
+live — but it does mean **none of them is as strong as written**, and the whole
+arrival question deserves re-running with cheap sampling before any conclusion
+is drawn from silence.
+
+## The fix: sample ~4 orders of magnitude less
+
+The full rescan is nearly all waste. After the first scan the craft bases and
+their roster links are already known, so a sample only needs the **hull word at
+each known base** — 300 × 4 bytes ≈ 1.2 KB, against 32 MB.
+
+`wave7_probe.py` does that: one full enumeration at the start, then cheap hull
+polling, with a full rescan only every ~90 s to catch anything genuinely new.
+That is 3–4 heavy scans per run instead of 25.
+
+Implemented, **not yet run** — so the claim that it stops the stalling is
+untested, and the next run must report the witness before anything else.