docs/re: three more runs, and eh_dispatch is still untested — with the proof why

Drove NEW GAME deliberately (the menu's first item, no d-pad, which is what the
run that first hit the crash actually did). Three runs with --eh_dispatch on: no
crash, no throw, black screen before the save-slot screen. It is tempting to read
that as the flag working.

The run with --cache_throw_diag as well disproves it. That cvar logs the throw
BEFORE any dispatch is attempted, so a throw would appear whatever dispatch then
did — and there were zero. No guest exception happened, so neither flag ran any
code, so neither can explain the difference. What took those runs out is the
intermittent content-load hang, before the crash path was reached.

eh_dispatch therefore stays untested, and the entry says so with the reasoning
rather than banking a false pass.

Confirmed on the way: the screen after NEW GAME is DIFFICULTY — its whole-image
signature matches the earlier capture exactly — so the menu path is understood
even though the runs die after it.

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

@@ -352,3 +352,32 @@ Neither has been beaten, and this run tested neither: it took a different branch
 through the menus than the run before it (TUTORIAL leads to a lesson list, and
 the DIFFICULTY screen captured earlier came from a different selection). The
 `--eh_dispatch` test needs a run that actually reaches `SELECT DATA`.
+
+### `--eh_dispatch` is still untested, and here is why that is a logical claim, not an excuse
+
+Three more runs, driving **NEW GAME** deliberately (the menu's first item, no
+d-pad — which is what the run that first hit the crash actually did, though it
+believed it had chosen TUTORIAL):
+
+| flags | reached | crash dumps | `GUEST-THROW` |
+|---|---|---|---|
+| *(none)* — earlier run | menu → DIFFICULTY → **SELECT DATA** | **537** | yes |
+| `--eh_dispatch=true` ×2 | menu → black | 0 | 0 |
+| `--eh_dispatch=true --cache_throw_diag=true` | menu → **DIFFICULTY** → black | 0 | **0** |
+
+The third row is the informative one. `cache_throw_diag` runs `LogGuestThrow`
+**before** any dispatch is attempted, so a throw would have been logged whatever
+the dispatch then did — and there were **none**. So no guest exception occurred
+in that run at all, and neither flag can have changed anything: both are inert
+until a throw happens.
+
+**Therefore the difference between the rows is not the flags.** It is the
+intermittent content-load hang, which took the run out before it reached the
+save-slot screen. The flag remains untested for the reason the runs record, and
+the temptation to read "0 crashes with `--eh_dispatch`" as a fix is exactly what
+the log disproves.
+
+Also confirmed on the way: the screen after NEW GAME is **DIFFICULTY** — its
+whole-image signature `(9.7, 19.5, 53.9)` matches the earlier capture of that
+screen exactly — so the menu path is understood even though the run dies after
+it.