re: the A-press dialog is the SIGN-IN dialog -- and the corpus already knew

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

docs/port/HANDOFF.md

@@ -2651,12 +2651,25 @@ XAM dialog happens to be up is *emulator* state — so "reproduced 4/4" and "it
 before" were both true all along.
 
 **For you, concretely:** nothing you ship changes. No disc fact moved, no screen,
-no timing. What changes is that the questions parked behind this — the BGM loop
-point (Q10) and whether menu music ducks under a cutscene — are no longer parked
-behind an unexplained crash. 🟡 They are not unblocked yet either: the route out is
-one of three (dismiss the dialog, `--headless`, or patch the swallow to return
-`X_ERROR_EMPTY`), none of them tried, and *which* dialog raises the flag is still
-unknown. Do not plan around a date.
+no timing.
+
+✅ **UPDATE, same day — the dialog is the SIGN-IN dialog, and there is no blocker.**
+The faulting runs booted with `logged_profile_slot_0_xuid = ""` — a profile exists,
+none is signed in — so Ⓐ 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.
+
+**The route out was already in the tree:** `tools/re-capture/boot_menu.sh` signs the
+existing profile in, which is why Q4 and Q5 pressed all five menu buttons. ⚠️ Not an
+A/B I have run myself — treat it as strongly supported rather than demonstrated
+until someone boots both ways.
+
+🔴 **And the honest part: the corpus already knew this and my page did not read it.**
+`canary-scripted-input-traps.md` §3 names the sign-in dialog with a capture, and
+`boot_menu.sh`'s header quotes the 8.4 M figure. What this session added is the
+*join* — that the known input blackout is what drives the guest's unbounded
+keystroke queue into a failed allocation. Recorded in
+[`METHOD.md`](../re/METHOD.md#before-calling-a-failure-unexplained-grep-the-corpus-for-its-symptom).
 
 Detail, with the disassembly and the log extract:
 [`docs/re/structures/title-a-press-fault.md`](../re/structures/title-a-press-fault.md)