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/re/REFUTED.md

@@ -35,6 +35,10 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "`sub_821C6458` is `GamePart_Title`'s state machine" → **mine, imprecise.** It
+  is the machine for **phase 4** of a five-way outer dispatch at `this+132`;
+  phase 0 is the splash. The ten states and eighteen edges are phase 4 only.
+  [`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)
 * "`sub_821CC860` is the game's by-name screen factory" → **mine, and wrong.** Its
   decoded arguments include `BG`, `BLACK`, `FADE`, `FILE`, `KEY`, `PAD`, `SOUND`,
   `GAMMA_RGB` — it is a **generic name-keyed lookup**, mostly config.