re: player death bounds every run; fix a harness bug that shortened the windows

Correction first. The sed used to derive each session script from the last
stripped the probe's arguments, so wave5, census and wave6 sessions invoked
their probes with no arguments and every derived probe has been running on its
own defaults. The previous iteration's claim that the run was "cut at 240 s by
the turn timeout, not the planned 330 s" is therefore wrong: the probe used its
default of 240. The pilot got the requested duration while the probe watched for
a different one, and the numbers were plausible enough that it went unnoticed.
No earlier conclusion is invalidated -- the windows were real, just shorter than
intended and misattributed. All three sessions now pass SECS and EVERY.

First n -> 0 ever observed: the player's own record went 2 -> 0 at t=83 s and
deployed fell 41 to 40. The signal does register elimination, not just damage.
No arrival followed, which is weak evidence against the squadron-elimination
trigger since the record eliminated was the player rather than an enemy
squadron. Two other turret records dropped from 18 in the same sample; noted
without interpretation.

The important finding is what came after. For the remaining 220 seconds the
mission was frozen -- exactly 288 craft, zero losses, zero arrivals, across 18
consecutive samples. So the usable observation window is not the probe duration
but however long the player survives. A 340 s probe that loses its pilot at 83 s
yields 83 s of evidence and 257 s of nothing, and several earlier "nothing over
240 s" results may have been much shorter in practice than they look.

That also explains why pilot.py was written to survive rather than to shoot. The
SYLPH_HUNT mode added two iterations ago drops TURRET_KEEPOUT from 2500 to 600,
buying kills at the cost of exactly the survival the run depends on.

The elimination test itself did not run: the squadron reached 14, not 0, before
the pilot died. What is needed is a pilot that kills and survives -- hunt turrets
but keep the evade and retire behaviour, or a keep-out between the two extremes.
That is tuning, not discovery.

docs/re/BACKLOG.md

@@ -373,9 +373,17 @@ search cannot find a *schedule*.
   longer covers those (it still covers t=170/210/240; the run was cut at 240 s by
   the turn timeout, not the planned 330 s). 🟡 **Sharper hypothesis:** the
   squadron ended at **2, never 0** — no squadron has ever been eliminated in any
-  run, so the trigger may be *elimination*, not damage. **Next: run ~60–90 s
-  longer so that squadron reaches 0, and watch for `0→n`** — a direct test of the
-  event-gated model.
+  run, so the trigger may be *elimination*, not damage. 🔴 **Elimination test UNRUN (2026-08-24)**: the hunting
+  pilot died at t=83 s with the squadron at 14. ✅ But the player's own record hit
+  `2→0` — first `n→0` ever seen, so the signal does register elimination (no
+  arrival followed; weak, it was the player not an enemy squadron). ✅ **KEY:
+  after player death the mission is frozen** — 288 craft, zero losses, zero
+  arrivals for 220 s / 18 samples. **The usable window is player survival, not
+  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.
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing: