tools: classify the mission briefing instead of filing it as menu

The briefing map is cyan and satisfies every clause of the menu rule (b-r > 30,
r < 45, little white), with no earlier rule claiming it -- so it was labelled
`menu`.  That made wait_screen.sh report NEVER REACHED READY ROOM on a run that
had successfully done LOAD GAME -> slot 01 -> YES and was three screens further
on: a working route scored as a failed one, pointing the next debugging step at
an input path that was fine.

Cyan has b and g nearly equal (b-g ~ 5) where the menu's blue leads its green
(b-g ~ 32), so `r < 20 and g > 30 and b - g < 20` separates them; the r floor
keeps the title screen out.  The file's own docstring already carried the
briefing's mean as an aside -- it just never had a class.

Verified against all eight signatures the file documents (2 menu variants, title,
ready room, flight, 3 briefing measurements): no regressions, and the captured
briefing image now reads `briefing`.

docs/re/screen-id-briefing-misclass.md

@@ -0,0 +1,60 @@
+# ✅ `screen_id.py` filed the mission briefing as `menu` — a successful route scored as a failure
+
+**Confidence: ✅ CONFIRMED and FIXED.** Measured 2026-08-26.
+
+## Symptom
+
+`launch_mission.sh`'s nav ran to completion and `wait_screen.sh readyroom 300`
+reported:
+
+```
+NO readyroom within 300s (last seen: menu)
+NEVER REACHED READY ROOM
+```
+
+The obvious reading — and the one taken at first — is that the presses after the
+main menu never landed. That reading was wrong twice over:
+
+1. Pad input *was* landing. With the game's own cursor counter as the oracle, two
+   `dpad down` presses moved it `24 → 26 → 28`.
+2. The run was not on the main menu. It was on the **mission briefing map**
+   ("Glasner Training Area", Ⓐ:Continue / Ⓑ:Back / START:Skip) — three screens
+   past the menu, i.e. `LOAD GAME → slot 01 → YES` had all worked.
+
+![briefing misread as menu](captures/briefing-misclassified-as-menu.png)
+
+## Cause
+
+The briefing is **cyan**; the menu rule tests for *dark and blue* and the
+briefing satisfies every clause of it — `b - r > 30`, `r < 45`, `white < 0.075`.
+With no earlier rule claiming it (the ready-room rule needs `b > 110`, the flight
+rule needs green), it fell through and was labelled `menu`.
+
+Ironically the file's own docstring already recorded the distinguishing number:
+it notes the briefing as "cyan rather than blue at (4.6, 47.7, 54.5)" — as an
+aside justifying the ready-room threshold, never as a class of its own.
+
+## Fix
+
+Cyan has blue and green nearly equal; the menu's blue runs far ahead of its green:
+
+| screen | measured means | `b - g` |
+|---|---|---|
+| briefing | (1.4, 45.2, 49.6), (5.5, 49.1, 54.3), (4.6, 47.7, 54.5) | ~5 |
+| main menu | (25, 38, 70), (13, 26, 59) | ~32 |
+
+So `r < 20 and g > 30 and b - g < 20` → `briefing`, placed above the menu rule.
+The `r < 20` floor keeps the title screen (52.8, 66.1, 74.5, `b - g` 8.4) out;
+the ready room (`b - g` ~97) and flight (green rule) are already claimed above.
+
+Verified against **every** signature the file documents — the two menu variants,
+title, ready room, flight, and three briefing measurements: 8/8 classify as
+intended, no regressions. The real capture above now reads `briefing`.
+
+## Why it mattered
+
+This is the expensive failure mode, not a cosmetic one: a route that *worked*
+was reported as broken, and the conclusion drawn from it — "the presses are not
+landing" — would have sent the next iteration to debug an input path that was
+fine. Compare the same file's earlier note about a run that "sat on a plainly
+visible MAIN MENU for 300 s": same class of bug, second occurrence.