docs: fold the launcher repair and the clean scan into the backlog

The launcher item closes: unattended boot to Stage 02 flight works again, and the
entry now names all three defects that were in the way, including the
wait_flight pixel that was outside the HUD.

The objective-counter item stays open but is sharper: a HUD-clean scan exists,
and the surviving candidate that is hard to dismiss is named with the odds
against it being chance. The blocker is now the pilot's survival, not the method.

Also withdraws yesterday's claim that the "Auto-Save is active. OK?" dialog does
not return - the run that appeared to show that was tapping A every six seconds
while it waited, so it cannot distinguish "absent" from "dismissed unseen".

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

docs/re/BACKLOG.md

@@ -216,11 +216,17 @@ shared checkout (202 files, no submodule churn), profile bootstrapped with the
 
 **Open, and cheap:**
 
-* 🔎 **`launch_mission.sh` does not finish unattended on restored state.** It now
-  reaches the READY ROOM and stops on **BRIEFINGS** — its `step up; tap A` for
-  TAKE OFF is swallowed because a fixed `sleep 28` precedes it. Replacing that
-  sleep with a wait for the screen (`screen_id.py`) is the whole fix. Both runs
-  on 2026-08-23 were finished by hand from where it stopped.
+* ✅ **`launch_mission.sh` finishes unattended again** (2026-08-23, later):
+  boot → title → LOAD GAME → slot 01 → READY ROOM → TAKE OFF → `IN FLIGHT at
+  34s`, pilot bound and engaging. Two defects, not one: the fixed `sleep 28` for
+  LOAD → READY ROOM (now `wait_screen.sh readyroom`), and the READY ROOM being
+  **drawn before it is usable** — `Preparing to Sortie`, TAKE OFF greyed, which
+  whole-image statistics cannot see (1.7 units of blue) so `take_off_armed.py`
+  tests the label. A third defect fell out of the same run: `wait_flight.sh` was
+  testing pixel (450,640) "inside the SHIELD bar" of a **1280×720** window, while
+  `screenshot` crops to the **1279×675** game surface — it lands between the
+  SHIELD and ARMOR bars. That is the long-standing "reported NEVER REACHED FLIGHT
+  while plainly in flight" note, now explained and fixed.
 * ❔ **Nothing guarantees this state survives the next container.** If it is
   meant to, the profile + save + `bin/` copies want a home inside a repo or a
   named volume; that is a call for the user, not for an agent.
@@ -236,9 +242,17 @@ the corrected method note (the scan takes **0.9 s** — the trap is the counter
 climbing `004 → 012` in four minutes, not scan duration) in
 [`structures/mission-objective-counter.md`](structures/mission-objective-counter.md).
 
+🟡 **A clean scan has now been run** (HUD confirmed `004` on both sides of it,
+filtered at a confirmed `012`): 17 candidates, one of which is **`0xbdb49668`** —
+the run-1 address minus exactly `0x10000`, same page offset `0x9668`, which only
+**2 of 39 596** candidates share. Amber, not green: the later sample landed
+during the GAME OVER flash with no HUD on screen, so the survivors are
+*unrefuted* rather than confirmed.
+
 **First step for whoever takes it:** a run whose pilot is still *engaging* when
-the scan happens, so a later transition exists to filter on — `pilot.py` had
-retired to hull 340/1500 and the counter then sat at `012` for five minutes.
+the scan happens, so a later transition exists to filter on. Both attempts so far
+died the same way — the escorted ACROPOLIS is lost while `pilot.py` sits in
+EVADE/RETIRE, and `REMAINING OB` then holds one value for ten minutes.
 The follow-on that the autopilot actually needs is unchanged and untouched:
 ❔ what the counter counts, and whether an `OB`-badged entity carries a flag in
 its entity object.

docs/re/dynamic-re-state-restore.md

@@ -124,9 +124,11 @@ lands one screen early — this run ended up sitting in **OPTIONS → GAME SETTI
 and `wait_flight.sh` correctly reported `NEVER REACHED FLIGHT`. The mission above
 was reached by driving the menus by hand from there.
 
-**Checked on the next boot: the dialog does not return** — the auto-save answer
-is kept in the profile. The launcher gets further (READY ROOM instead of
-OPTIONS) and still misses: it lands on **BRIEFINGS**, i.e. its
+**On the next boot the launcher gets further — READY ROOM instead of OPTIONS —
+but that run does NOT establish that the dialog is gone**, and the earlier
+wording here claiming it did is withdrawn: `wait_flight.sh` taps A every six
+seconds while it waits, so a dialog would have been dismissed by those taps
+without ever being seen. What run 2 does show is where it stopped: it lands on **BRIEFINGS**, i.e. its
 `step up; tap A` for TAKE OFF is swallowed by the READY ROOM transition, because
 what precedes it is a fixed `sleep 28` rather than a wait for the screen. So
 `launch_mission.sh` is **one wait away** from working unattended on restored