re: eliminate an enemy squadron — no wave follows; add a stall witness

SYLPH_KEEPOUT makes the hunt keep-out a knob instead of a hard-coded 600. At
1400 the pilot both kills and survives: hull 1500 and escorted asset 100 % for
the whole run, ENGAGE throughout, eight loss events against seven in the run
where it died at 83 s.

That let the elimination test actually run. An e007 Turret squadron was ground
18 -> 10 -> 8 -> 4 -> 2 -> 0, reaching zero at t=163 s with deployed falling 41
to 40 -- an enemy squadron destroyed outright for the first time in nine runs.

No arrival followed. ARRIVALS=0 at every sample including all those after t=163.
The hypothesis that a wave is released when a squadron is wiped out rather than
merely damaged does not survive its first test. Two further losses occurred at
t=176 and t=202, so the mission was demonstrably still live and still processing
kills; it simply produced no arrival. This refutes elimination-of-one-squadron
as the trigger. It does not refute event-gating generally -- a threshold across
several squadrons, an objective completion, or a specific squadron could all
still be the gate.

The valid window is smaller than the log suggests, about 90 s after the
elimination rather than 143 s, because the guest stalled around t=255 s. The
pilot's telemetry gives it away: the last 400 log lines contain one distinct
speed value against 236 in the first 400, with no timestamp gaps -- the process
kept logging while the game stopped advancing. Nothing in the probe output
distinguished a stall from a quiet mission, and the same ambiguity affects the
trailing flat samples of earlier runs.

wave6_probe now locates a counter advancing at frame rate, samples it each tick
and prints GUEST STALLED when it fails to advance, so future runs validate
themselves. Implemented but not yet exercised in a run.

docs/re/BACKLOG.md

@@ -382,8 +382,17 @@ search cannot find a *schedule*.
   probe duration.** 🔴 Harness bug found+fixed: a `sed` had stripped the probe
   args, so every derived probe ran on defaults — the previous "cut by the turn
   timeout" claim was wrong (it hit its own 240 s default).
-  **Next: a pilot that kills AND survives** (hunt turrets but keep evade/retire;
-  keep-out between 600 and 2500) — tuning, not discovery.
+  ✅🔴 **DONE + REFUTED (2026-08-24)**: `SYLPH_KEEPOUT=1400` gives a pilot that
+  kills and survives (hull 1500, asset 100 %, 8 losses). An enemy squadron was
+  **eliminated** — `e007 Turret 2→0` at t=163 s, `deployed` 41→40, first ever —
+  and **no arrival followed** in ~90 s of valid observation (two further losses in
+  that window prove the mission was live). ⇒ *"a wave is released when a squadron
+  is wiped out"* is **refuted**; event-gating generally is not (thresholds,
+  objectives, specific squadrons untested). 🔴 **Guest stalled at ~t=255 s** —
+  last 400 pilot lines have 1 distinct speed vs 236 in the first 400 — so trailing
+  flat samples in ANY earlier run may be a frozen guest, not a quiet mission.
+  Probe now carries a frame-rate tick witness printing `*** GUEST STALLED ***`
+  (implemented, **not yet run**).
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing: