docs/re: why a scripted run cannot get past the title — three traps and a blocker

Each of these presents as "the pad is dead", and each has a different cause.

1. **F10 opens the emulator's menu bar.** It is the RE capture hotkey AND the
   toolkit's menu key. With that menu open — or any Xenia UI window, the
   Profiles Menu included — `IsUIActive()` is true, so XamInputGetKeystrokeEx
   returns SUCCESS with a ZEROED keystroke before the pad driver is asked. The
   guest polls, gets nothing, and does nothing, with no error anywhere. Escape
   does not close it; a click on the game surface does. This cost most of an
   iteration.

2. **The file-pad was never the problem.** It delivers (vk=5800 down/up per tap)
   and A skips movies in the same runs.

3. **(A) at the title needs a signed-in profile.** Without one the guest calls
   XamShowSigninUI and Xenia's dialog appears — which is also the proof the
   guest reads the button. That dialog cannot be completed here: the gamertag is
   an ImGui text field and synthetic X key events never reach it. Hence Canary's
   new --create_profile_if_none.

And the blocker, stated as measured rather than as a theory: with the profile
signed in, (A) still does not advance the title across four boots. The
reproducible failure is next door — with the default --mem_watch=true the guest
crashes in the boot content path (read of 0x10000000C at 0x82307128, thread 9,
after a guest C++ throw), and with --mem_watch=false it does not. That is a
second, far cheaper reproduction of the Ready-Room crash the canary handoff
blames on the mem_watch probe: 40 s from a cold boot instead of after a mission.

One observation kept because it did not reproduce: a single (A) once crashed the
guest at a DIFFERENT PC (0x824578A0, thread 6). Two attempts to reproduce it
gave neither a crash nor a transition.

Next step named: those two PCs in xenia-rs/sylpheed.db, and the content exports
around the press.

docs/re/BACKLOG.md

@@ -143,6 +143,38 @@ been checked for one against this ground truth, and nothing yet explains how the
 two bundles are sequenced. Both are static questions again — the oracle side is
 answered.
 
+### 2026-08-18 (third pass) — the bundle does not carry the order at all
+
+Three more places checked, all empty, so the static avenue for this item is
+**exhausted** (detail and evidence in
+[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md)):
+
+- **the geometry has no depth.** A UI quad's attribute 0 is `k_32_32_32_FLOAT`,
+  so it carries a Z — and every Z in the capture is 0.00000. Submission order is
+  the entire ordering.
+- **the declaration table has no key.** Every word of every entry dumped for the
+  build the game actually runs: `+28` 0, `+32` `0xffffffff`, `+36` `0xffffffff`
+  (except an instance index on `kind = 0x4`), `+44` `0xffffffff`, `+56` 0.
+- **the placement region has none either**, including its per-group lead word,
+  which is 0 for all 24 groups; and the region is followed straight by the RATC
+  child stream, so there is no table hiding behind it.
+
+Also corrected: the running screen is **build 4**, not the largest build 7 that
+`screen info` defaults to — the two disagree on sprite sizes and the capture
+matches build 4. The conclusions are unchanged, the indices are not.
+
+**So the next step is the guest code**, not the file: the splash draw path from
+the emulator-era work (`sub_821CC7A0`, item vtable `0x820b30b4`) submits with
+exactly the PS hash `E59B2B3D` this capture sees, and `xenia-rs/sylpheed.db` is
+available in the container.
+
+**And a second screen is BLOCKED**, which is what this item wanted next: the
+title's Ⓐ leads into a content/save path that crashes the guest with
+`--mem_watch=true` and stalls it with `--mem_watch=false`. Three separate traps
+had to be cleared to establish that much — see
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md), which also
+carries the reproduction and the fix for two of them.
+
 
 ## Capital ships assemble wrong in the viewer