efee309d8f
screen_children.py walks every resident screen object (vtable 0x820b30b4), reads the element array at +0x08 and the child array at +0x30, and prints the paint permutation with each pivot. Validated in one run off the live title: it reproduces BOTH previously measured orders character-for-character - the splash [0,2,4,6,1,3,5] and the 24-element title permutation - so the next screen it is pointed at can be trusted. The screen that matters was not reached. GP_DIALOG DIFFICULTY carries exactly one primitive and would say whether the game paints it first or last, which is the bit that decides where primitives belong. But (A) does not advance the title screen at holds of 0.10, 0.25 or 0.40s, and neither does START, with the pad verified end to end: pad.py writes /tmp/xenia_pad.txt, the emulator runs with --hid=file --pad_file pointing at it, and the mtime updates on every press. The title is unambiguously the interactive one - PRESS (A) BUTTON is rendered. Recorded as a blocker rather than worked around. Next step is specific: boot with the emulator stdout kept and read the [RE-INPUT] IsUIActive log already present on the canary branch, which would say whether the keystroke is being swallowed emulator-side.