Answers the open half of the A-press diagnosis, and most of the answer was
already in the tree.
The faulting runs booted with logged_profile_slot_0_xuid = "" -- their own
config dump -- while a profile existed (Found 1 Profiles). With nobody signed
in, A takes the state-0 branch of sub_821D03A0 and calls XamShowSigninUI(1,1);
Canary raises its Sign In dialog with a no-op close handler and nothing in an
unattended run dismisses it. 85 instructions verified against the image, 0
mismatches; the state-3 branch is XamShowDeviceSelectorUI, already ruled out by
storage_selection_dialog = false.
The correlation runs through the tooling: boot_menu.sh passes the profile flag
and Q4/Q5 pressed all five buttons; frame_clock.sh, which produced the faulting
run, does not.
So there is no blocker -- boot with boot_menu.sh. Flagged as retrodicted rather
than A/B tested, since I have not myself booted both ways and pressed A.
The uncomfortable half: canary-scripted-input-traps.md section 3 already named
the sign-in dialog WITH a committed capture, and boot_menu.sh's header already
carried the mechanism and the 8.4 million figure. The fault page searched for
the cause it had hypothesised and never searched for its own symptom. Added to
METHOD.md, along with the more expensive lesson -- a measurement whose only
record is a script comment is invisible to the document that needs it.
What this session did add is the join: that the known blackout is what drives an
unbounded guest queue into a failed 128 MB allocation.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
8dfa0ebac5