re: recover the .slb leading segment — mono, and scoped by measurement

to_xma_riffs now emits the leading headerless segment when it sits at a whole
number of XMA1 packets and carries a non-zero byte. VOICE_D_453 goes from a
0.14 s trailing fragment to a 45116-byte leading sub-wave that dominates it.

I withdrew this exact change earlier for two reasons. Both are now answered
rather than argued away:

* "It recovers no audio" -- it used the STEREO format. At two channels every
  bank yields exactly 1792 bytes, one frame, whatever its size. Mono yields up
  to 113x more.
* "It matches 1524 of 8021 RIFF-bearing entries" -- the byte-level reach is
  still 1524, but the audible reach is not. Across the 84 movie-bound banks
  the segment adds >1 s to exactly 7, the hokyu_*_H tankers on D_453/D_454 --
  precisely the broken ones -- and <=0.25 s to 66 of the rest. The largest
  non-resupply addition is S04A at +0.66 s on a 256 s movie.

The safety oracle is recorded with its limits: 8 of the 84 banks ALREADY
exceed their movie's duration before the change, by hundredths of a second,
so it cannot resolve differences at that scale. It establishes scoping, not
correctness. Callers clamp to the movie length regardless.

VOICE_D_451's all-zero leading region is skipped by the non-zero guard, so
the rule cannot prepend silence to a bank that does not need it. Pinned, as
is the packet arithmetic (n = 8, 1, 7, 22, 29) which has no tunable.

slb_disc, movie_subtitle_disc and movie_manifest_disc all still pass.

NOT verified by ear -- that needs a human.

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

docs/re/BACKLOG.md

@@ -1057,9 +1057,18 @@ premise was wrong.**
   first `RIFF`. For the first three that discards only silence, so they looked
   fine (2.8 / 1.6 / 2.2 s); for the last two it discards **the line itself**,
   leaving 0.14 s and 0.43 s. One rule, two outcomes, depending on which segment
-  holds the speech. ▶️ The fix is now well-posed: emit the leading region **only
-  when it carries signal**, which also avoids the 1524-bank blast radius that
-  sank the earlier attempt.
+  holds the speech. ✅ **(same day) LANDED.** `to_xma_riffs` emits the leading segment
+  wrapped **mono** when it is a whole number of packets and carries a non-zero
+  byte. Both reasons the first attempt was withdrawn are answered: it used the
+  stereo format (mono yields up to 113× more), and while the byte-level reach is
+  still 1524 entries the **audible** reach is not — across the 84 movie-bound
+  banks it adds >1 s to exactly **7**, the `hokyu_*_H` tankers on
+  `VOICE_D_453`/`454`, and ≤0.25 s to 66 of the rest. ⚠️ The safety oracle is
+  weak and says so: **8 of the 84 already exceed their movie duration before the
+  change**, by hundredths of a second, so it establishes scoping rather than
+  correctness. Pinned by `tests/slb_leading_segment_disc.rs`, including that the
+  all-zero `VOICE_D_451` region stays skipped. ❔ Not verified by ear — that
+  needs a human.
 * ❌ **(2026-08-25) The `.slb` "multi-subwave" guess is REFUTED, and the voice
   decoder is discarding up to 87 % of a bank.** The record table gives a
   **direct** binding `hokyu_DS_s13A -> VOICE_D_452` where the corpus records the

docs/re/voice-bank-leading-region.md

@@ -1,7 +1,8 @@
 # The resupply voice banks — the decoder discards up to 87 % of them
 
-Status: ❌ the recorded "multi-subwave / not cleanly sliced" explanation is
-**REFUTED**. ✅ each shared bank is **one generic line**, which explains the
+Status: ✅ **FIXED** — `to_xma_riffs` now emits the leading segment as mono, and
+`VOICE_D_453`/`454` recover their line (`tests/slb_leading_segment_disc.rs`).
+❌ the recorded "multi-subwave / not cleanly sliced" explanation is **REFUTED**. ✅ each shared bank is **one generic line**, which explains the
 in-game verdict that rejected the `hokyu_DS_s13A` binding — the line really is
 generic. ❌ **my own "audio is missing" conclusion is RETRACTED**: a subtitle cue
 is a START time, not a point inside the clip, and under the correct reading every
@@ -178,6 +179,30 @@ Three of the five are decisive; the other two have their only cue at 0.0 s, whic
 tells us nothing in either direction. So **something is genuinely missing from
 these banks** — independent of anything above, and now measured rather than felt.
 
+## ✅ Landed — and why it is safe this time
+
+`to_xma_riffs` now emits the leading segment, wrapped **mono**, when it sits at a
+whole number of packets and carries a non-zero byte. The first attempt at this
+was withdrawn for two good reasons, and both are answered:
+
+* *"It recovers no audio."* It used the **stereo** format. Mono yields up to 113×
+  more, and `VOICE_D_453`'s 45 116-byte segment is now its largest sub-wave.
+* *"It matches 1524 of 8021 entries."* The byte-level reach is still 1524, but
+  the **audible** reach is not. Across the 84 movie-bound banks the segment adds
+  **more than 1 s to exactly 7** — the `hokyu_*_H` tankers on `VOICE_D_453`/`454`,
+  precisely the broken ones — and ≤0.25 s to 66 of the rest. The largest
+  non-resupply addition is `S04A` at +0.66 s on a **256 s** movie.
+
+The safety oracle is honest about its own limits: 8 of the 84 banks *already*
+exceed their movie's duration before the change, by hundredths of a second, so it
+cannot resolve differences at that scale. What it does establish is the
+**scoping** — the change is material only where it is meant to be. Callers clamp
+to the movie length regardless.
+
+`VOICE_D_451`'s all-zero leading region is skipped by the non-zero guard, so the
+rule cannot prepend silence to a bank that does not need it; that is pinned by a
+test.
+
 ## ✅ The two parts are SEQUENTIAL SEGMENTS — and that closes the original mystery
 
 The last open question was whether the leading mono region duplicates the RIFF