docs: REMAINING OB is at 0xbdb59668 - confirmed to the corpus's own standard

One filter to select (004 -> 008, 35897 -> 7), a second on a transition it was
NOT selected by (008 -> 012, 7 -> 1), leaving exactly one address; then three
live paired readings, RAM/screenshot/RAM, all agreeing with the HUD.

The address is the same one run 1 reported. That does NOT reverse yesterday's
refutation and the entry says so explicitly: runs 2 and 3 read a hard 0 there on
an allocated page while the HUD counted, so "it is there in every run" stays
refuted. What is withdrawn is the stronger claim that the number was meaningless
- it recurs exactly, in 2 of the 4 runs measured, and run 3's amber candidate
0xbdb49668 sits one 64 KB page below it at the identical page offset 0x9668. The
practical rule is therefore: try 0xbdb59668, check it against the HUD, re-scan
when it reads 0.

Why run 3 failed and run 4 did not is also recorded, because it is a method
lesson rather than luck: the evidence was always in the first four minutes of the
stage, and the earlier runs simply could not look often enough - every HUD
reading cost a human round trip, so the 008 step went by between two of them.

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

docs/re/captures/ob-hunt-stage02-run4.json

@@ -0,0 +1,21 @@
+{
+ "scan_value": 4,
+ "transitions": [
+  {
+   "from": 4,
+   "to": 8,
+   "survivors": 7
+  },
+  {
+   "from": 8,
+   "to": 12,
+   "survivors": 1
+  }
+ ],
+ "survivors": [
+  {
+   "off": 4793407080,
+   "va": 3182794344
+  }
+ ]
+}

docs/re/captures/ob-hunt-stage02-run4.log

@@ -0,0 +1,4 @@
+scanned at 004: 35897 candidates
+004 -> 008  [SELECTED ON]  7 survive
+008 -> 012  [verification (unselected)]  1 survive
+  va 0xbdb59668