docs/re: the main menu HAS been reached — the Ⓐ blocker is withdrawn

The previous entry called the title's Ⓐ a hard blocker. It is not: the main menu
is reached and screenshotted (NEW GAME / LOAD GAME / TUTORIAL / OPTIONS /
EXTRAS). What is true is narrower — Ⓐ advances the title only intermittently,
about one attempt in four, with the press verifiably delivered every time and no
Xenia UI active.

Three candidate causes were eliminated with measurements rather than argument:

* IsUIActive is now observable (Canary logs when it swallows a keystroke) and it
  never fires on the failing runs;
* the driver filter is fine — the game polls with flags=3 and the file pad
  reports Controller=1, so FilterDrivers keeps it;
* the game makes no content/user/signin call on the press at all — tracing every
  Xam call around it shows only input polling.

And two traps in my own measuring rig, which cost more than the bug and are
written down so nobody repeats them: a FIFO trace consumer that exits STALLS the
emulator (the guest stops polling — indistinguishable from a dead pad, and it
produced two runs of false evidence), and phase-A's kernel.return events carry a
placeholder return_value of literally 0, so "every keystroke call returns
SUCCESS" was an artifact of the logger, not a finding.

docs/re/BACKLOG.md

@@ -168,7 +168,15 @@ 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
+**And a second screen is NO LONGER BLOCKED, but it is not routine either.** The
+main menu has been reached (screenshot in
+[`canary-scripted-input-traps.md`](canary-scripted-input-traps.md)), so the
+"Ⓐ is dead" reading is withdrawn; what remains is that Ⓐ advances the title only
+intermittently — one success in about four tries, with the press verifiably
+delivered each time. A reliable route to the menu is the next cheap step, and it
+is what the second screen's capture needs.
+
+The earlier reading, kept because it is what the evidence looked like: 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