formats: drop the 1.5 MB cap that truncated 17 voice regions' first stream

The cause, and the fix, with a disc-wide check.

resolve_movie_voice_region picks start = the predecessor cue's trailer, then
filtered it with 'end - s < 1_500_000' -- 'only within one bank'. ADV's
predecessor sits 3 618 816 B before end, so the filter rejected it and start fell
back to anchor, which is a TOC offset and not a stream boundary. That explains
the shape of the defect exactly: it strikes regions larger than 1.5 MB, which is
why the three-stream multichannel regions are hit and single-stream ones never
are. 17 of 95 resolving movies took the fallback.

ADV's predecessor trailer at 433 425 776 plus 17 040 B of descriptor and padding
is 433 442 816 -- the -238-packet start measured against the decoder, to the byte.

Dropping the cap: unchanged 78, fixed cleanly 17, changed in any other way ZERO.
In all 17 the only difference is a larger first chunk with every later chunk
byte-identical, which is what a corrected start looks like and what pulling in a
neighbouring asset does not.

Regression test pinned to the RUNNING DECODER's byte_sizes rather than to this
crate's own output. That is the point of it: every internal check passed happily
while a third of a stream was missing, so only an external number could have
caught this class of bug.

sylpheed-formats: 136 tests pass, 0 fail (the one still running at commit time is
an unrelated long mesh test).

Exact clips for the other 16 are not independently verified -- the sweep is
strong but ADV is the only one with a decoder measurement behind it.

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

docs/re/structures/voice-region-starts-late.md

@@ -77,11 +77,54 @@ clipped chunk 0; the quantitative argument there survives because it quotes a
 **ratio** test explicitly chosen to be immune to the clipping, but the absolute
 level for chunk 0 was measured over 62 % of the stream.
 
-## ⚠️ What is NOT fixed here
+## ✅ WHY — and it is fixed (2026-08-30, later)
 
-**The resolver is unchanged.** This page establishes that its start is wrong for
-these regions and by how much for one of them; it does not derive the correct rule.
-`voice_region_chunks.rs`'s own note says the region *"starts at the PREDECESSOR
-cue's trailer"* — so the question is why that trailer lands 238 packets into the
-next asset, and that is not answered. Recorded rather than patched, because a fix
-guessed from one movie would be worse than a documented defect.
+The predecessor trailer does **not** land 238 packets into the next asset. It is
+never consulted: a second condition on the start filter threw it away.
+
+```rust
+.filter(|&s| s < end && end - s < 1_500_000)   // "only within one bank"
+```
+
+`ADV`'s predecessor sits **3 618 816 B** before `end`, so the filter rejects it and
+`start` falls back to `anchor` — **a TOC offset, which is not a stream boundary at
+all**. That is the whole mechanism, and it explains the shape of the defect
+exactly: it strikes regions *larger than 1.5 MB*, which is why the multichannel
+three-stream regions are hit and the single-stream ones never are.
+
+| | |
+|---|---|
+| `ADV` predecessor trailer | 433 425 776 |
+| + descriptor and padding | 17 040 B |
+| = stream start | **433 442 816** — the −238-packet start, to the byte |
+
+**17 of the 95 resolving movies** took the fallback.
+
+### ✅ The fix, and its disc-wide check
+
+Dropping the cap (keeping `s < end`):
+
+```
+anchor (today)          start 433930240  ->  [806912, 1118208, 1171456]
+predecessor (proposed)  start 433425776  ->  [1294336, 1118208, 1171456]   MATCHES
+```
+
+| | movies |
+|---|---|
+| unchanged | **78** |
+| fixed cleanly — first chunk grows, every later chunk byte-identical | **17** |
+| **changed in any other way** | **0** |
+
+Zero. In all 17 the *only* difference is a larger first chunk, which is what a
+corrected start looks like and what pulling in a neighbouring asset does not.
+[`../data/voice-region-cap-sweep.txt`](../data/voice-region-cap-sweep.txt).
+
+**Landed** in `media.rs`, with a regression test pinned to the **running decoder's**
+byte_sizes rather than to this crate's own output —
+`adv_voice_region_holds_all_three_decoded_streams`. That distinction is the point:
+every internal check passed happily while a third of a stream was missing, so only
+an external number could have caught it.
+
+⚠️ **Exact clips for the other 16 are still not independently verified.** The sweep
+shows their first chunk grows and their tails are untouched, which is strong; but
+`ADV` is the only one with a decoder measurement behind it.