f6f8930ee7
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.