docs/re: the title-screen crash is an STL map/set erase, 40 s from a cold boot

The crash PC from the previous iteration resolves, and it names itself:
sub_823070B0 references the string 'invalid map/set<T> iterator', builds it with
the string helpers and throws it — which is the guest C++ exception (E06D7363)
Xenia reports one line earlier. Its node offsets are MSVC's red-black tree node
exactly (_Left 0, _Parent 4, _Right 8, _Color 24, _Isnil 25), so this is a
std::map/set erase, and the fault is the first dereference after the iterator
check.

That matters beyond this blocker. The canary handoff's Ready-Room crash is the
same shape — a guest STL exception in a cache/save path — and its bisection plan
is priced at "one build plus one Ready-Room run" per suspect. If it is the same
defect, each suspect now costs 40 seconds, and suspect #1 is already measured:
--mem_watch=false removes it.

Stated as unresolved rather than guessed: the fault address 0x1_0000000C is a
32-bit value with bit 32 set, which fits BOTH a corrupt guest tree and a stale
high word on the emulator side. The measurement that separates them (read the
node from guest memory at the throw) is written down rather than assumed.

The second, unreproduced crash PC is identified too: an unrolled 4x16-bit copy
loop faulting on the STORE, i.e. a bad destination — a different failure.

docs/re/canary-scripted-input-traps.md

@@ -104,11 +104,18 @@ C++ exception in a cache/save path. This is a second, far cheaper reproduction o
 it: at the **title screen**, ~40 s from a cold boot, instead of in the Ready Room
 after a mission.
 
-**Next step, for whoever picks this up.** Two threads to pull, in this order:
+**The first of those next steps is done**, and it moves the crash out of this
+entry into its own: `0x82307128` is inside an MSVC `std::map`/`set` **erase** —
+the function carries the string `'invalid map/set<T> iterator'` and the node
+offsets to prove it — which makes this a 40-second reproduction of the crash the
+Canary handoff blames on the `mem_watch` probe. See
+[`title-crash-stl-tree.md`](title-crash-stl-tree.md).
 
-1. `0x82307128` and `0x824578A0` in `xenia-rs/sylpheed.db` (the container has it)
-   — what function is the title's Ⓐ path in, and what is at `+0xC` of the
-   structure it dereferences;
+**Next step, for whoever picks this up.** What is left:
+
+1. dump the tree nodes from guest memory at the throw, to separate "the guest's
+   tree is corrupt" from "the emulator left a stale high word in a register" —
+   the fault address `0x1_0000000C` is consistent with either;
 2. the content exports this title imports — `XamContentCreateEnumerator`,
    `XamContentGetDeviceState`, `XamUserReadProfileSettings` — logged around the
    press, to see whether the guest is handed a bad enumerator or a device state