re: it is not a stage-load freeze -- the game freezes entering MISSION SELECT

The whole page called this a stage-load/take-off freeze.  Wrong, and the
evidence was in each run's own screenshots.

nav_to_flight.sh saves a shot per step.  Compared CONSECUTIVELY:

    01-extras -> 02-missionselect   rmse 51.07, 99.42% changed
    02-missionselect -> 03-selected rmse  0.00,  0.00% changed
    03 -> 04 -> 05 -> 06 -> 07 -> 08-flight   all 0.00

Shots 02 through 08 are pixel-identical.  The screen stops at MISSION SELECT and
never changes.  Every later step the script reports -- selected, readyroom,
takeoff, flight -- is it pressing buttons at a frozen image while screen_id.py
classifies a static frame.

Withdrawn as a result:

  * "MISSION SELECT and the stage list worked, the failure came later during the
    take-off load".  It froze entering MISSION SELECT.
  * challenge-mission-gate.md §5.6 already said entering MISSION SELECT fails on
    a 128 MB request and shows "Disc Read Error".  It was right; I contradicted
    it because my navigation script claimed to have got further.
  * Every "reached flight" in this session is false, including runs where
    screen_id.py returned "flight".

Method note kept on the page: the first comparison ran every shot against shot 1
and returned rmse 51.07 / 99.42% for all seven, identical to two decimals across
seven different images.  That is a tell, not a result.  I then talked myself out
of it because md5sum showed eight distinct hashes -- which was PNG metadata.
Compare consecutive frames, and treat a suspiciously constant statistic as a bug
in the measurement.

Consequence for the oracle: the allocation failure happens while the display is
already frozen, so it is downstream, which fits the three runs that froze with
the allocation succeeding at 16, 32 and 128 MB.  MISSION SELECT is the thing to
avoid -- every route this session used goes EXTRAS -> MISSION SELECT, and
newgame_path.sh / tutorial_launch.sh reach a mission by other menus.

docs/re/mission-freeze-heap-exhaustion.md

@@ -452,3 +452,63 @@ allocated at **boot**, before any menu, so 171 MB of the 379.5 MB is fixed
 regardless of route. The remaining ~208 MB is where a route difference could
 live, and the ledger can measure it: capture live-bytes at the moment TAKE OFF is
 pressed, for two different navigation paths, and compare.
+
+---
+
+# 🔴🔴 It is not a *stage-load* freeze at all — it freezes at MISSION SELECT
+
+**2026-08-26.** Everything above calls this a stage-load or take-off freeze. That
+is **wrong**, and the evidence was in the run's own screenshots the whole time.
+
+`nav_to_flight.sh` saves a shot at each step. Comparing them **consecutively**
+(not all against the first — see the mistake below):
+
+| transition | rmse | pixels changed |
+|---|---|---|
+| `01-extras` → `02-missionselect` | 51.07 | 99.42 % |
+| `02-missionselect` → `03-selected` | **0.00** | **0.00 %** |
+| `03` → `04` → `05` → `06` → `07` → `08-flight` | **0.00** | **0.00 %** |
+
+Shots **02 through 08 are pixel-identical**. The screen stops at MISSION SELECT
+and never changes again. Every step the script then reports — *selected*,
+*after-A*, *readyroom*, *takeoff-hl*, *flight* — is it pressing buttons at a
+frozen image, and `screen_id.py` classifying a static frame.
+
+[`captures/freeze-at-missionselect.png`](captures/freeze-at-missionselect.png) is
+the frame it dies on.
+
+## 🔴 So several claims on this page are withdrawn
+
+* **"`MISSION SELECT` and the stage list worked, and the failure came later,
+  during the take-off load"** — withdrawn. It froze *entering* MISSION SELECT.
+* **`challenge-mission-gate.md` §5.6 was right and I contradicted it.** It says
+  entering `MISSION SELECT` fails on a 128 MB request and Xenia surfaces a *"Disc
+  Read Error"*. That is exactly this. I read my own runs as getting further
+  because the navigation script said so.
+* **Every "reached flight" in this session's runs is false**, including the ones
+  where `screen_id.py` returned `flight`. A single-frame classifier cannot tell a
+  live screen from a frozen one — already noted on this page, and it still fooled
+  me because I trusted the *script's* progress log instead of the frames.
+
+## ⚠️ The comparison mistake, recorded because it nearly buried the result
+
+The first pass compared every shot against **shot 1**, and got
+`rmse=51.07, changed=99.42%` for all seven — identical to two decimals across
+seven supposedly different images. That is not a result, it is a tell, and I
+briefly took it as "all frozen", then talked myself out of it when `md5sum`
+showed eight distinct hashes. The hashes differ only in PNG metadata. **Compare
+consecutive frames, and treat a suspiciously constant statistic as a bug in the
+measurement, not a finding.**
+
+## ❔ What this changes about the oracle
+
+The allocation failure happens *while the display is already frozen*, so it is
+downstream of whatever wedges the game, not the cause — consistent with the three
+runs that froze with the allocation succeeding, stopping at 16 MB, 32 MB and
+128 MB respectively.
+
+The actionable consequence: **MISSION SELECT is the thing to avoid.** Every route
+this session has used goes EXTRAS → MISSION SELECT. The 2026-08-10 run that flew
+for 500 s did not necessarily; `newgame_path.sh` and `tutorial_launch.sh` reach a
+mission by other menus. Testing a non-MISSION-SELECT route is the next
+experiment, and it is now the most promising one available.