port: BLOCKED -- the paint-order tie-break costs zero pixels on every screen we ship

The old figure was 24 overlapping tied pairs, and it was a rest() count: 10 of
the title's 11 tied pairs are between the five transient flashes, which are
transparent on a settled screen. Measured at settle, the cost is ZERO on all five
screens this port ships, and the only non-zero anywhere in GP_TITLE is 1 px at
delta 1 on the Japanese title, which is out of scope. Sweeping every keyframe
time and midpoint, the live-pair count is flat across the settle window, so it is
not a knife-edge.

Recorded with the Decoder's own caveat rather than smoothed: four loading bundles
report zero with no live control, so those are a weaker zero than the other six.
And why ties order as they do is still unknown -- it now costs one pixel.

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

docs/port/BLOCKED.md

@@ -96,6 +96,7 @@ HANDOFF.
 
 | Milestone | Needs | HANDOFF | State |
 |---|---|---|---|
+| ~~P1–P7 — the paint-order tie-break~~ | ~~how many pixels can a wrong tie-break cost?~~ | Q3 | ✅ **MEASURED TO ZERO on every screen this port ships, 2026-08-29** (`docs/re/structures/ui-tie-break-cost-at-settle.md`). The old figure — 24 overlapping tied pairs — was a `rest()` count, and **10 of the title's 11 tied pairs are between the five transient flashes**, which are transparent on a settled screen. The only non-zero anywhere in `GP_TITLE` is **1 px at Δ1 on the Japanese title**. Not a knife-edge either: sweeping every keyframe time and midpoint, the live-pair count is flat across the whole settle window. ⚠️ Four loading bundles report zero with **no live control**, so those are a weaker zero than the other six. ❔ *Why* ties order as they do is still unknown — it now costs one pixel, on a screen out of scope. |
 | P4/P7 — the intro's dialogue | ~~why the intro has no voices~~ | Q9 | ✅ **answered and TAKEN 2026-08-29, and the obvious diagnosis was wrong.** Not a transcode fault: `ADV.wmv` carries music and effects only, and a cutscene's voice is a *separate* continuous XMA stream in `sound.pak` bound by the movie manifest. `audio::export_voice` now resolves it with `media::resolve_movie_voice_region` — never by filename, because `RT01A`'s voice lives inside `VOICE_ADV.slb` and a name match is right on exactly the two movies this port would have spot-checked. This is **decoded, nothing authored**. ⚠️ **This row's original text said the region's chunks are "concatenated (one continuous stream), not summed" — that was the first of three wrong readings and it is superseded**; see the incomplete-export row below for where it ended up. Left visible rather than silently rewritten, because the sequence of wrong readings is what makes the final one checkable. |
 | P4/P7 — the movie downmix | **is the exporter allowed to ship a matrix MISSION §6 did not pin?** | — | 🔴 **with the HUMAN, not the Decoder, and now visible for the first time.** §6 pins the 5.1 fold as a human decision of 2026-08-29; `video.rs` has shipped that matrix scaled by **0.4142** since P4 — same weighting, **7.65 dB quieter** — and said so nowhere. Re-measured this iteration with the right instrument (float decode, whole file, count the samples that would clamp, not a peak reading): under the **pinned** matrix `ADV` peaks at **+4.26 dBFS** with **4 406** samples at or over full scale and 1 874 more than 1 dB over, while `S00A` peaks at −1.34 dBFS and **never clips**. So the pin overloads one movie and the exporter's constant is over-broad for the other. Smallest single scalar under which neither clamps: **0.612**, +3.39 dB on today. **Not changed** — the level of a mix is what §6 reserves. The export now carries a manifest warning with these numbers. |
 | ~~P4/P7 — a voice region's chunks~~ | ~~what is the leading chunk, and is the second one played?~~ | — | ✅ **CLOSED 2026-08-29, decoded disc-wide, and it cost this exporter three wrong readings in one session.** A region carries **three presentations of one take** — the Decoder counted stream starts inside every inter-descriptor span: 258 spans hold one, 28 hold three, nothing holds two (`auto/no-disc-and-menu-captures` at `801062c`). So `359 = 84.55 + 137.32 + 137.32`. My concatenation was wrong, my "two stems" reading was wrong (and had already been adopted into the Decoder's page before I tested it — withdrawn in both), and summing was wrong a third time because a take plus a 0.60× copy of itself is ~4 dB louder and coloured. The exporter now keeps **one stream** and does no arithmetic on it. The leading chunk is this movie's own dialogue, and I measured it to be the **tail** of the kept stream (r=0.998 / 0.932, controls 1.000 and 0.289), so dropping it removes a duplicate. 🟡 **What is left open is which presentation to keep**: the selector is highest byte rate on the Decoder's recommendation, nothing on the disc says which the game plays, and on `ADV` it picks the quieter of two. Settled by a capture of the movie's dialogue level. ❔ Why the disc stores three at all is unanswered by either agent. |