re: the title-menu screens read the auto-save (slot 01), and the high score is computed not stored

Two results, both from a safe probe.

Slot 03 was given SHAB[0] = (a=1, b=12345, c=60000) -- a one-minute best time --
and MISSION SELECT still showed 4612 P EASY / 05:24.77 EASY, i.e. slot 01's
numbers. So the title-menu screens read the AUTO-SAVE, and any probe written to
a throwaway slot is invisible there. The previous SHAB identification is
unaffected: it matched slot 01's own bytes, which is what the screen renders.

The consequence is a decision, not a task: mapping the difficulty enum (a) or
testing b needs slot 01 itself edited -- the only save with real progress. Left
undone deliberately and flagged in the doc; a full content backup exists and
slot 01's bytes are archived, so it is recoverable, but it is the user's call.

Also: High Score 4612 is stored NOWHERE. It is absent from both .gpd profile
files, all three saves (compressed and inflated) and xconfig.settings, while the
best time 324773 is present in slot 01 alone. The score is computed at display
time, which is why SHAB[0].b = 4101 does not equal it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/re/structures/savegame-format.md

@@ -277,7 +277,30 @@ record" guess to ✅ for the layout, with the time field named exactly.
 Evidence: [`captures/mission-select-stage01-record.png`](../captures/mission-select-stage01-record.png).
 The route is `EXTRAS → MISSION SELECT` from the title menu; only cleared stages
 are selectable (16 d-pad presses never left Stage 01), and the screen carries its
-own **difficulty selector** (`Y`).
+own **difficulty selector** (`Y`) — that selector is the *next run's* difficulty,
+while the `EASY` beside each record is the difficulty the record was set on.
+
+**The title-menu screens read the auto-save (slot 01), not the newest slot.**
+Tested: slot 03 was given `SHAB[0] = (a=1, b=12345, c=60000)` — a one-minute best
+time — and MISSION SELECT still showed `4612 P EASY / 05:24.77 EASY`, i.e. slot
+01's numbers. So a probe written to a throwaway slot is **invisible** on these
+screens.
+
+Two consequences. First, the identification above is unaffected — the match was
+against slot 01's own bytes, which is exactly what the screen renders. Second,
+**mapping the difficulty enum (`a`) or testing `b` requires editing slot 01**, the
+only save carrying real progress. That is deliberately not done here: it is the
+user's call, and it is the one edit in this whole line of work that is not
+trivially reversible from a throwaway copy. (A full content backup exists at
+`/sylph-home/re/content-backup-2026-08-11-preSaveRE`, and slot 01's bytes are
+archived, so the call is *recoverable* — it is still not mine to make.)
+
+One more thing this settles: **`High Score 4612` is not stored anywhere.** It is
+absent from every file in the content tree — both `.gpd` profile files, all three
+saves (compressed and inflated) and `xconfig.settings` — while the best time
+`324773` is present in slot 01 alone. So the score shown on that screen is
+**computed at display time** from stored fields, which is why `SHAB[0].b = 4101`
+does not equal it.
 
 ## What this does and does not unlock