docs: a clean scan for REMAINING OB, and one candidate that is hard to dismiss

With the launcher repaired the scan could be run the way the method asks: the HUD
was confirmed at 004 immediately before AND after the 0.9 s scan, and the filter
was taken at a confirmed 012. That leaves 17 candidates from 39596.

One of them is 0xbdb49668 - the run-1 address minus exactly 0x10000, at the same
page offset 0x9668. Checked rather than admired: of all 39596 words holding 4 at
scan time, exactly TWO sit at that page offset, so a survivor landing there by
chance is a ~5e-5 event. The reading it suggests is testable - the counter sits
at a fixed offset in an allocation whose base moves by whole 64 KB pages.

Recorded as amber, not green, and the reason is written down: the later sample
that killed 10 of the 17 was taken during the GAME OVER flash, with no HUD on
screen, so the seven survivors are unrefuted rather than confirmed. The mission
ended because the escorted ACROPOLIS was lost at ~13 min while pilot.py sat in
EVADE/RETIRE; REMAINING OB held at 012 for the ten minutes before that, so there
was no transition to verify against.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/mission-objective-counter.md

@@ -107,3 +107,46 @@ that is still *engaging*, which is the same constraint
 
 **Unchanged and still open:** what the counter counts, and whether an `OB`-badged
 entity carries a flag in its entity object. Nothing in this pass touched that.
+
+## 🟡 2026-08-23 (later) — a third run, a HUD-clean scan, and one candidate that is very hard to explain away
+
+With the launcher repaired the scan could finally be run the way the method
+asks. **HUD confirmed `004` immediately before *and* after the scan** (0.9 s), so
+the 39 596-entry candidate set is valid at that value; then filtered when the
+HUD was confirmed at `012`.
+
+| step | HUD | candidates |
+|---|---|---|
+| scan | `004` (confirmed both sides) | 39 596 |
+| filter | `012` (confirmed) | **17** |
+| later sample | — (see caveat) | 7 still 12 |
+
+**The survivor of interest is `0xbdb49668`** — the run-1 address `0xbdb59668`
+**minus exactly `0x10000`**, at the identical page offset `0x9668`.
+
+**That is not a cheap coincidence, and it was checked rather than admired.** Of
+all 39 596 words holding `4` at scan time, exactly **2** sit at page offset
+`0x9668`; one of those two is in the 17, and it is this one. A survivor landing
+there by chance is a ~5 × 10⁻⁵ event. The reading it suggests — the counter lives
+at a fixed offset inside an allocation whose **base moves by whole 64 KB pages**
+between runs — is a testable claim, not a story: a third scan should again land
+on `…9668`.
+
+**Why this is 🟡 and not ✅, stated plainly.** The corpus's own rule is that a
+candidate is believable once it tracks a transition it was *not* selected on,
+against the HUD. This one has not done that yet:
+
+* The "later sample" that killed 10 of the 17 was taken **during the GAME OVER
+  flash** — the escorted ACROPOLIS was lost at ~13 min — so the HUD counter was
+  not on screen. The ten that *moved* are genuinely refuted; the seven that did
+  not move are merely **unrefuted**, which is a much weaker thing, and the
+  counter may simply be frozen once the mission ends.
+* Between the filter and the mission end, `REMAINING OB` sat at `012` for about
+  ten minutes: `pilot.py` spent the window in EVADE/RETIRE at hull 822/1500 and
+  killed no objectives, so there was no transition to use.
+
+**The one experiment that settles it:** a run where the pilot is still engaging,
+scanning and filtering as above, then watching `0xbdb4·9668`-equivalent across a
+HUD-verified change. The blocker is the pilot's survival, not the method — and
+the same run would answer whether the page offset repeats, which is the stronger
+result of the two.