re: S00A is unreachable here -- the new-game path crashes on a cache it cannot build

Drive 4 worked. With focus detected and the detector validated live against a
known transition (NEW GAME, down, LOAD GAME -- CONTROL PASSED), the drive
navigated and pressed through, and every step confirms against a committed
capture: main menu +0.999, newgame-difficulty +0.999, newgame-selectdata-crash
+0.997. Then the guest throws, PC 0x82307128 times 349, and no S00A voice stream
ever decodes.

It is on the new-game path rather than the boot: the log order is ADV attract,
then BGM_103 menu music, then the throw. So it is not the ~100 s boot throw that
title-crash-stl-tree.md documents.

That page attributes the throw to an incomplete on-disc cache and Q4 s note cites
it for this crash. The attribution survives, but not through the container the
page names. aab216c3 is complete here at 7 files. The line immediately before the
exception resolves \1b556564\9\00c8dcd, and 1b556564 holds exactly one file plus
a stray 1b556564900c8dcd.tmp -- precisely the page s run C, partially rebuilt,
which throws. So the new-game path builds a different cache container from the
title path and that one is incomplete.

The page s remedy does not transfer. It restores a previously complete cache, and
no complete 1b556564 has ever existed here: the game crashes while building it,
leaving the .tmp, so the cache cannot complete and re-running does not escape it.
Its own run B shows a fully cold cache throws as well, so deleting does not help.

Consequence recorded: the centre-channel voice result stays resting on ADV alone,
because the corroborating asset is behind a crash that is outside menu-port scope.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/re/s00a-drive-blocked-by-focus.md

@@ -1,4 +1,8 @@
-# 🔴 The `S00A` capture failed — the menu's initial focus was TUTORIAL, not NEW GAME
+# 🔴 `S00A` is unreachable here — the new-game path crashes on an on-disc cache it cannot finish building
+
+**Four drives.** The first three failed on tooling and are recorded below because
+each defect is live in shared scripts. The fourth drove perfectly and hit a
+**guest crash**, which is the real answer.
 
 **Classification: measured.** Two drives, 2026-08-29. Reported as a **route
 finding** rather than retried silently, because the cause is a defect in shared
@@ -90,3 +94,66 @@ The offset-independent check settles it without needing that geometry at all:
 NEW GAME → EXTRAS. ✅ **The port's identification stands.** ⚠️ And as they
 themselves noted, it identifies *one frame*, not a rule: Q5's instability is
 untouched.
+
+---
+
+## ✅ Drive 4 — the drive worked; the GAME crashes at `SELECT DATA`
+
+With focus detected and the detector validated **live against a known
+transition** (`NEW GAME` → ⬇ → `LOAD GAME`, expected `LOAD GAME`, **CONTROL
+PASSED**), the drive navigated to `NEW GAME` and pressed through. Every step is
+confirmed against a committed capture:
+
+| step | correlates with | r |
+|---|---|---|
+| after navigation | `main-menu-items.png` | **+0.999** |
+| after Ⓐ | `newgame-difficulty.png` | **+0.999** |
+| after Ⓐ (NORMAL) | `newgame-selectdata-crash.png` | **+0.997** |
+
+Then the guest throws: **`PC: 0x82307128` ×349**, one
+`Guest attempted to throw a C++ exception!`. No `S00A` voice stream ever decodes.
+
+✅ **It is on the new-game path, not the boot.** Ordering in the log is
+`ADV` (attract) → **`BGM_103`** (menu music, i.e. the menu was reached) → throw →
+crash dumps. So this is *not* the ~100 s boot throw that
+[`title-crash-stl-tree.md`](title-crash-stl-tree.md) documents.
+
+## 🟡 Refining that page — the mechanism holds, the container does not
+
+That page attributes the throw to an **incomplete on-disc cache**, and Q4's note
+says the `SELECT DATA` crash "is already in the corpus", citing it. **Checked,
+and the attribution survives — but not via the container the page names.**
+
+| cache container | state here | |
+|---|---|---|
+| **`aab216c3`** — the one the page names | **7 files, complete** | not the trigger |
+| **`1b556564`** — resolved immediately before the throw | **1 file + `1b556564900c8dcd.tmp`** | ⚠️ exactly the page's **run C**, "partially rebuilt (1 file + a `.tmp`) → 1 GUEST-THROW" |
+
+The log line before the exception is
+`HostPathDevice::ResolvePath(\1b556564\9\00c8dcd)`. So the **new-game path
+builds a different cache container from the title path**, and it is that one
+which is incomplete.
+
+🔴 **And the page's remedy does not transfer.** Its fix is to restore a
+*previously complete* cache (run D). **No complete `1b556564` has ever existed in
+this container** — the game crashes while building it, leaving the `.tmp`, so the
+cache cannot complete and the crash cannot be escaped by re-running. The page's
+own run B shows a fully cold cache throws too, so deleting it does not help
+either.
+
+## The answer
+
+❔ **`S00A` is not obtainable in this container**, and the reach is:
+
+* the drive is **not** the obstacle — four screens confirmed against committed
+  captures at r ≥ 0.997, and the focus detector passed a live transition control;
+* the obstacle is a **guest crash** with a known site and a known class of
+  trigger;
+* the documented remedy needs an artefact — a complete `1b556564` — that has
+  never existed here and that the game cannot produce because it crashes
+  mid-build.
+
+⚠️ **Consequence for the voice finding:** the centre-channel result stays resting
+on `ADV` alone. `S00A` was wanted because its second stream is digital silence
+where `ADV`'s is a 0.60 × copy; that corroboration is **not available from this
+container** without first solving a crash that is outside the menu-port scope.