re: confirm, move and back -- every cue the five screens need is now

located, and two of them reproduce

Continuing Q8 rather than opening anything new. The gap that mattered was
the confirm cue: a menu needs a sound on A, and I had only cursor and
cancel.

The fix was where I was counting from. The first run started counting
streams at the main menu, so the confirm cue had already fired during
boot and showed up as "played before any input". Counting from the TITLE
instead attributes it cleanly: the A that advances title -> main menu
fires the 12288-byte wave at 0x5d6c0, together with the two stereo BGM
stems, which is the menu's music starting.

So move (0x1ec0, 0.533 s), confirm (0x5d6c0, 1.016 s) and back (0x0ec0,
0.344 s) are all located and decodable. Move and back came back with
IDENTICAL head bytes and sizes on a second independent boot, so the
dedup-keyed method is stable and those two are now n=2 rather than n=1.

Two honest limits recorded rather than smoothed over. The A press both
confirms and opens a screen, so its wave could be the cue the vocabulary
calls DECIDE or the one it calls SUB_WIN_OPN -- the port gets the sound
the game plays, not a name. And left/right fired no new stream, which
excludes a DISTINCT invalid cue but cannot exclude them quietly replaying
one of the three already heard, because the probe dedups on head bytes.

docs/port/HANDOFF.md

@@ -170,10 +170,18 @@ authored version can be deleted.
   executable — those extensions are the authoring tool's). But Canary's
   `--xma_param_probe=true` logs every stream's head bytes, and searching them in
   `Static.slb` locates the wave exactly:
-  **d-pad move → `0x1ec0`, 4 packets / 8 192 B, mono 48 kHz; Ⓑ back → `0x0ec0`,
-  2 packets / 4 096 B.** Each matched at one offset only, and they are contiguous
+  **d-pad move → `0x1ec0` (4 pkts / 8 192 B, 0.533 s); Ⓐ confirm → `0x5d6c0`
+  (6 pkts / 12 288 B, 1.016 s); Ⓑ back → `0x0ec0` (2 pkts / 4 096 B, 0.344 s)** —
+  every cue the five screens need. Move and back reproduce with identical head
+  bytes across **two independent boots**. Each matched at one offset only, and
+  the first two are contiguous
   (`0x0ec0 + 4096 = 0x1ec0`) — the bank is a packed run of whole 2 048-byte
   packets with no delimiters, which is why nothing could be scanned for.
+  ❔ **⬅ and ➡ play nothing distinct** — no new stream on either, so leave them
+  silent (the probe dedups, so this excludes a *distinct* invalid cue, not a
+  quiet replay of an already-heard one).
+  🟡 The Ⓐ press both confirms and opens a screen, so whether its wave is the cue
+  named `SE_UI_DECIDE` or `SE_UI_SUB_WIN_OPN` is not separated.
   ⚠️ The order is **not** cue-id order, so the index must be observed per cue, not
   counted. ✅ **The slices decode**: 0.533 s, 0.344 s and 1.016 s of mono 48 kHz
   audio with the attack-and-decay shape of UI blips, via
@@ -258,7 +266,8 @@ here until 2026-08-28 and is now settled.)
 
 | | what | why it is stuck |
 |---|---|---|
-| 🟡 | **cue NAME → event binding** (Q8) | the event→**wave** binding is now measured; that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still read off the authors' identifiers |
+| 🟡 | **cue NAME → event binding** (Q8) | event→**wave** is measured for move/confirm/back; that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still read off the authors' identifiers |
+| ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
 | 🟡 | **the paint-order tie-break** (Q3) | eight candidates refuted; costs one element's blend on one screen |
 | 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
 | ❔ | **the boot transitions in code** (Q6) | bounded as code-not-data, not proven. `sub_821C6458` — the substantial function in `GamePart_Title`'s neighbourhood — has **not been read** |