port: the resolver starts late, and my 'duplicate tail' was a real stream

My refusal to apply their weights found a defect in their decoder:
resolve_movie_voice_region starts 238 packets (487424 B) inside ctx0 for ADV, and
8 of 10 three-chunk regions start mid-stream disc-wide.

That re-reads one of my own measurements without touching it. I had the leading
chunk as 'the TAIL of the kept stream' at r=0.998, lag flush against the end, and
dropped it as a duplicate. If the streams are simultaneous and the region starts
238 packets into ctx0, the surviving fragment is ctx0's later 62%, which aligns
flush against the end -- exactly what I measured. Same number, opposite meaning:
a start-truncated simultaneous stream, not a duplicate. The port drops a real one.

I suspected the instrument first, since they had just shown envelope correlation
saturating at 0.86-0.95 across stream/channel pairs. Tested on the dialogue: r =
1.0000 at zero offset, -0.08..+0.08 elsewhere. It localises sharply; their
saturation is concurrent streams at zero lag, a different regime. So the tool was
sound and the error was entirely in the inference.

Not fixed: including chunk 0 needs their corrected span (they say do not extend
blind -- only ADV's clip is known) or an alignment decision I would be inventing,
since the chunk is missing its head.

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

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-127 sections. Search this before re-deriving anything.
+128 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -138,6 +138,7 @@ dies, which is what this file is for.
 * [My rendered pulse, counted in their units — and #4 refutes the voice value without fixing it](#my-rendered-pulse-counted-in-their-units--and-4-refutes-the-voice-value-without-fixing-it)
 * [The voice export now carries every qualifying stream — and a unity sum was refused by our own check](#the-voice-export-now-carries-every-qualifying-stream--and-a-unity-sum-was-refused-by-our-own-check)
 * [Their stream assignment does not fit my region — weights NOT applied](#their-stream-assignment-does-not-fit-my-region--weights-not-applied)
+* [The resolver starts late, and my "duplicate tail" was a real stream all along](#the-resolver-starts-late-and-my-duplicate-tail-was-a-real-stream-all-along)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -7445,3 +7446,55 @@ of 0.9s reads as a strong finding and is the opposite. **Sample-level correlatio
 returns ≈ 0**, because the XMA decode's framing offset is unknown. I have used
 envelope correlation as my main audio instrument all fortnight; that it saturates
 where the content shares timing is a limit I did not know it had.
+
+## The resolver starts late, and my "duplicate tail" was a real stream all along
+
+My refusal to apply their weights found a defect in their decoder:
+**`resolve_movie_voice_region` starts inside the first stream.** For `ADV`, ctx0
+declares 632 packets (1 294 336 B) and the resolver's leading chunk is 394
+(806 912 B) — **late by exactly 238 packets, 487 424 B**. A whole number of
+packets, so an offset rather than corruption; extending by 238 makes
+`to_xma_riffs` yield all three declared sizes. Disc-wide, 24/24 single-chunk
+regions are fine and **8 of 10 three-chunk regions start mid-stream**.
+
+### 🔴 Which re-reads a measurement of mine, without touching the measurement
+
+This port measured the leading chunk as *"the TAIL of the kept stream"* —
+envelope correlation r=0.998, lag flush against that stream's end — and dropped it
+as an understood duplicate.
+
+**The correlation was right and the conclusion was wrong.** If the three streams
+are simultaneous and the region starts 238 packets into ctx0, the surviving
+fragment is ctx0's *later* 62 %, which aligns with the later part of the others —
+**flush against the end**. That is precisely what I measured. Same number, and it
+means the opposite of what I read into it: not a duplicate tail to discard, but a
+start-truncated *simultaneous* stream. **The port has been dropping a real stream.**
+
+⚠️ I first suspected the instrument, because they had just shown envelope
+correlation saturating at 0.86–0.95 across every stream/channel pair. Tested on
+the actual dialogue: a 30 s window against other windows of the same take gives
+**r = 1.0000** at zero offset and **−0.08 … +0.08** everywhere else. It localises
+sharply. Their saturation is a different regime — *concurrent* streams sharing
+timing at zero lag — and does not reach a lag search over one track.
+
+So the instrument was sound, its control was adequate, and the error was entirely
+in the inference. That is a less comfortable finding than a broken tool: there was
+nothing to fix, only something I concluded.
+
+### Not fixed here, deliberately
+
+The port still drops chunk 0. Including it correctly needs one of two things I do
+not have:
+
+* **the corrected span** — theirs, and they explicitly say not to extend blind:
+  `ADV` is start − 238×2048, but for the other seven affected regions the exact
+  clip is **unknown**, their audit's figure being an upper bound (243 for `ADV`
+  where the truth is 238);
+* **or an alignment decision** — chunk 0 is missing its *head*, so summing it from
+  sample 0 would be wrong by 84.5 s against 137.3 s. Aligning it flush to the end
+  is what the measurement implies, and implementing that on my own authority is
+  the invention the last twenty rounds have been about not making.
+
+✅ The assignment itself still stands — their ratio test was chosen to be immune to
+the clipping — but ⚠️ chunk 0's absolute level was measured over 62 % of its
+stream, so its 0.05 dB agreement is luckier than it reads.