re: phase 0 is the splash, phase 2 is the title -- and a candidate answer

to this corpus's oldest input puzzle

Continuing Q6 on the phases left unread. Strings each phase handler
references, plus whether it carries its own jump table:

  phase 0  sub_821C5690   LOGO                                    no switch
  phase 2  sub_821C5818   BASE_INFO, BUTTON, TITLE_SCREEN         no switch
  phase 3  sub_821C5EC0   (none)                                  one switch
  phase 4  sub_821C6458   BASE_INFO, LOADING, TITLE_MENU, TITLE_SCREEN

Phase 0 referencing LOGO is a second independent confirmation that it is
the developer splash -- the iterate3E notes reached the same function
from the guest side and named the splash's LOGO items. Phase 2 draws the
title WITH the PRESS A plate, which the archive side had already
established is a build of its own.

Which produces something worth more than either: the title is installed
from TWO places, phase 2 and phase 4 state 0. Same screen, different
code. canary-scripted-input-traps.md has recorded for months, and never
explained, that the boot title accepts A while the attract-returned title
accepts nothing, with the giveaway that a draw capture in each is
identical. Two code paths installing one screen is exactly that shape. I
have written it into that page as a candidate with the cheap test named
-- read this+132 on each title -- and marked it untested, because it is.

One query in this iteration failed its own control and I threw its half
away: counting stw rX,136(r30) per phase returned 0 for phase 4, which
has 18, because the operand text has a space the pattern did not allow.
The bctr half passes its control and is reported. METHOD gets the
underlying trap: instructions.function is unpopulated for most rows, so a
query scoped on it silently returns nothing.

docs/re/METHOD.md

@@ -226,3 +226,8 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   rather than a whole wave. They match `BGM_103` exactly — the check had covered
   only the `BGM_0xx` rows of the census, because that is the block that had been
   on screen.
+* **`instructions.function` is unpopulated for most rows in `sylpheed.db`.** A
+  query keyed on it returns *nothing* rather than erroring — a `bctr` search
+  scoped that way reported "no jump tables" for a function with two known ones.
+  Scope by `address between <start> and <end_address>` instead, and gate any such
+  query on a function whose answer you already know.