re: ran the decode test -- the bank data does not continue past the TOC window

Read VOICE_TCAF_608's full declared 759808 bytes out of the flat stream ignoring
window boundaries. It decodes to the same 896 bytes (0.01 s) as stopping at the
window end -- 86x more input, zero extra samples. Control VOICE_D_452, whose
declared size fits, decodes to 2.18 s normally. No segment join is crossed, so
the packing phase is not a confound.

So 'the bytes are outside the window but still in the stream' does not hold for
the one bank the other branch named as not truncated. I still withdraw my word
'truncated' as an over-claim about the other 5295 banks: I measured that their
declared size exceeds their window, not what lies beyond it, and have now tested
exactly one. Recorded the three claims at their actual strengths.

docs/re/structures/slb-data-offset.md

@@ -321,10 +321,30 @@ with a bank's data simply continuing past its window. But "declared sizes are
 exact" requires a wave to span many named entries, which is a much stronger
 claim than "the bytes are outside the window".
 
-❔ **Unresolved.** The other branch's own open question — *"which bank in a window
-belongs to the entry's name (some windows hold two, ids drift)"* — is the same
-question from the other side, and settling it is what would decide this.
-**First step**: take `VOICE_TCAF_608`, read 759 808 bytes from its `data` chunk
-straight out of the flat stream ignoring window boundaries, and decode. If it
-yields ~8 s of continuous speech, the data really does span windows; if it turns
-to noise at the window edge, it does not.
+### ✅ The experiment was run — the data does not span windows
+
+Read `VOICE_TCAF_608`'s declared 759 808 bytes straight out of the flat stream,
+ignoring the window boundary, and decoded through FFmpeg's `xma1`:
+
+| read | bytes in | decoded |
+|---|---|---|
+| `data` → window end | 8 864 | 896 bytes = **0.01 s** |
+| `data` → full declared size | **759 808** | 896 bytes = **0.01 s** |
+| control `VOICE_D_452`, declared fits | 26 624 | 208 970 bytes = **2.18 s** |
+
+**Reading 86× more bytes yields not one extra sample.** The bytes past the
+window are not this bank's audio, so "the bytes are outside the TOC window but
+still in the `.pNN` stream" does not hold here — and this is the very bank the
+other branch named as *not* truncated. (No segment join is crossed: the read
+sits inside `sound.p02`, so the packing phase is not a confound.)
+
+So for `VOICE_TCAF_608` the audio really is not present. I still withdraw the
+word **"truncated"** as an over-claim about the other 5 295 banks — I measured
+that their declared size exceeds their window, not what is in the bytes beyond
+it, and I have now tested exactly one of them. What is established is narrower
+and worth stating exactly:
+
+* ✅ the declared `data` size exceeds the TOC window for 5 296 of 7 586 banks;
+* ✅ for `VOICE_TCAF_608` the missing bytes cannot be recovered from the stream;
+* ❔ whether that generalises is **untested** — the same decode would have to be
+  run across the population, which is the obvious next step and was not done.