re: record the REMAINING OB hunt in the backlog index

The previous commit landed the doc and the probes but its BACKLOG edit asserted
on text that had since moved, so the index did not mention the hunt at all.

That is the third time an assert-then-replace patch has silently failed this
way. The pattern is the problem: the assertion aborts the edit but the commit
that follows still succeeds, so a missing index entry looks like a clean run.
Locating the anchor first and verifying the insert afterwards, as done here, is
the habit to keep.

docs/re/BACKLOG.md

@@ -574,6 +574,18 @@ search cannot find a *schedule*.
   already knew this** — several iterations reconstructed it the hard way;
   `grep -rl TextIndex crates/` would have saved the detour. ❔ Minor: `ixud.rs`
   says UTF-16BE, `localization.rs` says LE — one comment is wrong.
+* ✅🔴 **(2026-08-24) REMAINING OB hunt: method works, run unfinished**
+  ([`remaining-ob-hunt.md`](remaining-ob-hunt.md)). Correlate heap words against
+  *named* kill events instead of scanning for a value: **one `e010` event cut ~8 M
+  words to 1056**. 🔴 But the probe saved candidates only at the END and the turn
+  timeout discarded them — **the exact mistake already recorded in
+  `guest-stalls.md` four iterations earlier**. 🔴 And the follow-up attach logged
+  535 s of zero losses with **no stall witness**, so it cannot say whether the
+  guest was quiet or frozen. Both fixed (save per event + `SYLPH_OB_RESUME=1`
+  resume; witness carried over). **Pattern worth acting on: each new probe starts
+  from scratch and re-earns the same lessons — a shared probe harness would stick
+  where written-down lessons have not.** Needs 2–3 `e010` events, i.e. the same
+  combat limit.
   🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
   most kills, so pilot polling is not the throttle.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;