re: the ten states are ONE PHASE of five -- and phase 0 is the splash

Chasing where the event code comes from turned up the level above and
corrected my own framing three sections running.

sub_821C6458 has exactly one caller, sub_821C7850, and that caller is
itself a dispatcher -- on a SECOND, outer state field at this+132, five
phases, gated on this+16 == 3. Phase 4 is the title/menu machine I have
been decoding. Phase 0 is sub_821C5690, which the iterate3E notes had
already fingered as the splash mechanics from a completely different
direction. That agreement is the useful check here.

So GamePart_Title has two nested state fields: a phase at this+132
choosing which sub-machine runs, and the state at this+136 inside phase
4. Everything I decoded over the last three iterations -- ten states,
eighteen edges, the event dispatch -- is phase 4 ONLY. Phases 1, 2 and 3
are untouched. I have called that out in REFUTED against my own earlier
wording rather than quietly restating it.

And the event code is forwarded, not created: all five phase handlers are
called with the same (this, r29, r28), where r28 is sub_821C7850's own
third argument passed through untouched. So the event vocabulary is
defined at least one level further up, and finding what 3, 5, 8, 10 and
25 mean means going up again. Not done.

docs/port/HANDOFF.md

@@ -212,6 +212,11 @@ authored version can be deleted.
   `LOADING`. `4 → 0` is the only edge back to the title, reached from `2 → 4` —
   which matches Ⓑ-returns-to-title as measured. Full graph in
   [`data/title-state-machine.txt`](../re/data/title-state-machine.txt).
+  ⚠️ **All of that is ONE PHASE.** `GamePart_Title` dispatches on an outer phase
+  field at `this+132` (five values) before reaching any of it: phase 0 is the
+  **developer splash** (`sub_821C5690`, the same function the corpus fingered
+  independently), phase 4 is the title/menu machine. The ten states and
+  eighteen edges above live inside phase 4 alone.
   ✅ **State 4's edge conditions are an event code** — `sub_821C6458`'s third
   argument. State 4 is the input-waiting state (reached straight after the menu
   is installed) and handles 6 of 26 events: **`0` → title**, **`3`, `5`, `8`,
@@ -296,7 +301,7 @@ here until 2026-08-28 and is now settled.)
 | ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
 | 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen |
 | 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
-| 🟡 | **the boot transitions in code** (Q6) | state machine **decoded** (10 states, 18 edges) and state 4's edges are selected by an **event code** — 6 of 26 handled: `0`→title, `3/5/8/25`→`LOADING`, `10`→state 5. Still unknown: what the event *numbers* mean |
+| 🟡 | **the boot transitions in code** (Q6) | `GamePart_Title` has **two nested state fields** — a 5-way phase at `this+132` (phase 0 = the splash, phase 4 = title/menu) and a 10-way state at `this+136` inside phase 4, with 18 edges selected by an **event code**. Unknown: what the event *numbers* mean, and phases 1–3 |
 | ❔ | **builds 0/1 and 10/11**, the `DELTASABER` plates (Q2) | never seen anywhere in the boot path, the title-side screens or the attract loop. A mission load is the remaining candidate and this container kills runs before one completes |
 
 (An earlier version of this table called the audio items blocked on "an emulator