re: 69.8% of banks declare more data than they store -- and that explains TCAF_608

Of the 7586 banks with a RIFF and a data chunk after it, 5296 declare a data
size larger than the pak entry holds; 2290 declare less (the ordinary
multi-sub-wave case); NONE declare exactly what they hold. This contradicts the
decoder comment claiming the declared size 'is honest per sub-wave'. The code
clamps, so it is a documentation defect, not a crash.

It also closes the loose end from the offset work: eng\Voice\VOICE_TCAF_608,
the single bank where neither offset decoded, is 99% short -- there is nothing
there to decode.

Method note recorded: my first pass searched for 'data' from offset 0, which can
match by chance inside the leading audio region. Anchoring the search after the
first RIFF moved the count 5038 -> 5296.

Separately, the 55 'early RIFF' English banks are not an anomaly: all 55 sit at
exactly 1392 behind a zero-filled header -- a zero-length leading region, which
both the old and new code already handle correctly.

docs/re/BACKLOG.md

@@ -31,8 +31,13 @@ mistaken a constant derived from `eng\etc\` for a property of the format. See
 `Pj_Silph.xgs`, named by the same table's `BANK_SE` and `SETTINGS` records —
 `sound.pak` is now 9 519 of 9 519 accounted for.
 
-**Still open**: 55 English banks have their first `RIFF` at or before offset
-1392, and the 28 offset-scan ties.
+**Closed**: the 55 "early `RIFF`" English banks are not an anomaly — all 55 sit
+at *exactly* 1392 behind a zero-filled header, i.e. a zero-length leading
+region, which both the old code and the new derivation already handle.
+
+**Still open**: the 28 offset-scan ties, and ❔ why 69.8 % of banks declare more
+`data` than they store (see
+[`structures/slb-data-offset.md`](structures/slb-data-offset.md)).
 
 ---