120a8ee50c
First run with the tick witness. It flagged a stall from t=27 s and every sample after, and the pilot's own telemetry -- which the probe never reads -- agrees: 35 distinct speed values across the whole log and exactly 1 in the last 400 lines, against 236 in the first 400 of a healthy run. All variation is in the first ~50 s. The witness is validated. It earned its keep on that same run. Without it the output reads as "no arrivals across 313 seconds with 300 craft resident" -- clean, quotable and completely worthless, because the game was frozen for 90 % of it. Rule adopted: a run whose witness reports a stall is discarded, and every write-up states the witness result. Flat samples are not evidence unless the witness says the guest was advancing. Stalls are frequent and early. The last three long runs stalled at roughly 255 s, 83 s (after the player died) and 27 s. That makes long observation windows unreliable, and long windows are exactly what the arrival question needs. Leading suspect is the probe itself, and it is recorded because it is uncomfortable rather than despite it. AGENT.md warns that a full memory scan competes with the emulator for every core under lavapipe, and these probes have grown heavier each iteration: wave6 now reads the entire 32 MB entity heap plus about 300 extra preads every 12 seconds while the game renders. If that is the cause, the instrument has been degrading the thing it measures and the earlier "no arrival" results were collected under conditions the game was struggling with. Next is a control that needs no new decoding: run the hunting pilot for 300 s with no probe at all and judge from the pilot log alone. If it does not stall, sampling has to get much cheaper -- narrow the scan to the roster region, sample less often, or reread only the craft bases already located instead of rescanning the heap. The multi-squadron kill-threshold test did not run: the guest froze before anything was destroyed, so there were no losses to threshold.