re: which challenge stage is which leaderboard mode - CLOSED from the record's own fields

challenge-mission-gate.md section 5.3 left a marked 🟡 on the exact pairing and named
the right route: read the record's binary index section rather than the string pool.
Running that with the corpus's own reader settles all six missions at once.

  TimeAttack    MISSION_ID 24  REQUIREMENT 16  RECORD_TYPE Time
  ScoreAttack   MISSION_ID 25  REQUIREMENT 24  RECORD_TYPE Points
  Extra01       MISSION_ID 26  REQUIREMENT 25  RECORD_TYPE Points
  Extra02       MISSION_ID 27  REQUIREMENT 26  RECORD_TYPE Time
  Extra03       MISSION_ID 28  REQUIREMENT 27  RECORD_TYPE Time
  Extra04       MISSION_ID 29  REQUIREMENT 28  RECORD_TYPE Points

Control: the table appears in 6 pak entries, all in tables.pak, and all six are the
same table byte for byte - one per language, i.e. one user under the per-pak copy
rule. Zero variants.

Three things fall out, none of them assumed. MISSION_ID is the stage number: the six
IDs are 24-29 in slot order, exactly the six challenge stages S24-S29, bijectively -
so the "four Extra0n modes against five _EXn stages" worry dissolves, because _EXn is
a unit-variant suffix that indexes nothing here. REQUIREMENT is a strict chain, 16,
24, 25, 26, 27, 28, each mission requiring the previous one's stage with TimeAttack
anchored on stage 16, the final story mission; 5.3 inferred a chain from the shape of
the string pool, and it is now exact and branchless. RECORD_TYPE is the leaderboard
metric and it is per-stage, not per-name: 3 Time (S24, S27, S28) and 3 Points (S25,
S26, S29), so the tempting reading that the Extra0n family shares one metric is
wrong - Extra01 and Extra04 are Points while Extra02 and Extra03 are Time.

Withdrawn from 5.3: the string-pool reading listed the numeric tokens as 16, 25, 26,
27, 29 with 24 and 28 deduped away. The real REQUIREMENT set is 16, 24, 25, 26, 27,
28 - 29 is a MISSION_ID, never a requirement. A value pulled from a deduped pool by
adjacency got one member wrong; the indexed read has no such failure mode.

Left as an association rather than a proof: RECORD_TYPE takes exactly the two values
Points and Time, and result-screens names two ranking screens POINT_RANKING and
CLEAR_TIME_RANKING, but no code path has been shown selecting one screen from that
field.

All seventeen artefacts byte-identical.

docs/re/BACKLOG.md

@@ -7028,3 +7028,34 @@ menu modes, mission select, and an equip screen carrying the typo
 
 🟡 Open: the 38 bare screens cannot be named by key list. 🟡 Whether the `EX_`
 in `EX_MENU_DISABLE_SKIP` / `EX_LETTERS` is the `+184` `EXTRA` word.
+
+---
+
+## ✅ 2026-08-28 — which challenge stage is which leaderboard mode: CLOSED
+
+Read from the mission record's own indexed fields (the route
+`challenge-mission-gate.md` §5.3 itself named), with the corpus's reader:
+
+| `TimeAttack` 24/req 16/**Time** | `ScoreAttack` 25/req 24/**Points** | `Extra01` 26/req 25/**Points** |
+|---|---|---|
+| `Extra02` 27/req 26/**Time** | `Extra03` 28/req 27/**Time** | `Extra04` 29/req 28/**Points** |
+
+**Control: 6 pak entries, all `tables.pak`, all byte-identical — one user.**
+
+✅ **`MISSION_ID` is the stage number** — `24`–`29`, bijective with challenge stages
+S24–S29. The "4 `Extra0n` vs 5 `_EXn`" worry dissolves: `_EXn` is a unit-variant
+suffix indexing nothing here.
+
+✅ **`REQUIREMENT` is a strict chain** — `16, 24, 25, 26, 27, 28`: each mission needs
+the previous one's stage, anchored on stage 16. §5.3 guessed the chain from pool
+shape; it is now exact and branchless.
+
+✅ **`RECORD_TYPE` is the metric, per-stage not per-name** — 3 `Time` (S24, S27, S28)
+/ 3 `Points` (S25, S26, S29). The `Extra0n` family does **not** share one metric.
+
+⚠️ **Withdrawn**: §5.3's pool reading gave requirements `16,25,26,27,29`; the true set
+is `16,24,25,26,27,28` — **`29` is a `MISSION_ID`, never a requirement**.
+
+🟡 `RECORD_TYPE`'s two values match the two ranking screens `POINT_RANKING` /
+`CLEAR_TIME_RANKING` by vocabulary, but no code path selecting one from that field
+has been shown.