re: REMAINING OB by correlation — method works, run unfinished, two repeat defects

The objective text settles what the counter is, so the hunt can be a correlation
rather than a value scan: keep every word in the 32 MB heap that fell by the same
amount, in the same interval, as a named e010 loss. One event cut roughly eight
million words to 1056, so two or three more should leave a handful.

The run did not get them. The turn's timeout fired at t=219 s and the probe saved
its candidate set only at the end, so the 1056 were discarded and the follow-up
attach started from nothing. That is the same mistake already recorded in
guest-stalls.md, where an earlier probe deferred all analysis to the end and a
timeout killed it with 240 s of data in memory and nothing written. The lesson
was written down and then repeated in a new script four iterations later.

The attach had a second gap: 535 s with zero losses of any kind, which is
indistinguishable from a freeze, and ob_probe2 carried no stall witness so the
run cannot say which it was.

Both are fixed. Candidates are written after every event and SYLPH_OB_RESUME=1
reloads them so a chained attach keeps intersecting on the same mission, and the
witness from wave7_probe is carried here.

The underlying pattern is worth naming: each new probe starts from scratch and
re-earns the same lessons about saving incrementally and validating liveness. A
shared probe harness would stick where written-down lessons have not.

The hunt itself is unfinished. No address is identified, and finishing needs a
run that catches two or three marked-fighter kills, which is the same
combat-effectiveness limit already recorded -- about two per five minutes against
a dozen turrets.

docs/re/remaining-ob-hunt.md

@@ -0,0 +1,63 @@
+# Hunting REMAINING OB by correlation — method works, run did not finish
+
+Status: ✅ the correlation method is sound and demonstrated; 🔴 the hunt is
+**unfinished**; 🔴 two self-inflicted defects, one a repeat.
+
+## The method
+
+[mission-phase-objectives.md](mission-phase-objectives.md) settles what the
+counter is: Stage 02 phase 1 asks to *"shoot down all invading enemy fighters"*
+and the hints say red **[OB]** markers indicate the targets. So `REMAINING OB`
+must fall when a marked fighter dies — and the per-record craft strength already
+says exactly when that happens, for a *named* unit.
+
+So instead of scanning for a value, intersect: keep every word in the 32 MB heap
+that fell by the same amount, in the same interval, as an `e010` loss. Each kill
+event should cut the survivor set hard.
+
+`tools/re-capture/ob_probe2.py`.
+
+## ✅ It works — one event cut 8 million words to 1056
+
+```
+t= 219s  e010 losses=2 (all=4)  words falling by 2: 1056  -> candidates 1056
+```
+
+From ~8 M candidate words to **1056** on a single event. Two or three more should
+leave a handful.
+
+## 🔴 The run did not finish, and the candidates were lost
+
+The turn's timeout fired at t = 219 s, and the probe saved its candidate set
+**only at the end** — so the 1056 were discarded. The follow-up attach then
+started from nothing.
+
+**This is the same mistake already recorded in
+[guest-stalls.md](guest-stalls.md)**: "the first attempt deferred all analysis to
+the end of the run, and the turn's timeout killed it with 240 s of collected data
+still in memory and nothing written." I wrote that lesson down and then repeated
+it in a new script four iterations later.
+
+Fixed: candidates are now written to `/tmp/ob_candidates.json` **after every
+event**, and `SYLPH_OB_RESUME=1` loads them so a chained attach keeps
+intersecting on the same mission.
+
+## 🔴 The attach could not tell a quiet mission from a frozen one
+
+The follow-up attach logged **535 s with zero losses of any kind**. That is
+exactly what a freeze looks like, and `ob_probe2` had no stall witness, so the
+run cannot say which it was. Also fixed — the witness from `wave7_probe` is now
+carried here.
+
+Two defects in one iteration, both of them things this corpus had already
+learned. The pattern is that each new probe starts from scratch and re-earns the
+same lessons; the fix that would actually stick is a shared probe harness rather
+than a family of one-off scripts.
+
+## What is still open
+
+The hunt itself. The method is demonstrated but no address is identified. What it
+needs is a run that catches **two or three** `e010` kill events, which is the same
+combat-effectiveness limit recorded in
+[mission-objectives-text.md](mission-objectives-text.md) — the preference knob
+gets about two marked-fighter kills per five minutes against a dozen turrets.