re: the paint-order tie-break costs one pixel, on one screen we do not ship

Closes the open half of Q3. `ui-paint-order-derived-check.md` bounded WHERE a
wrong tie-break could show -- overlapping same-key pairs -- and said outright
that nobody had measured how many change a pixel.

At the instant the player sees, the answer is: at most 1 px at max channel
difference 1, on the JAPANESE title only (`ptlogo2` x `ptlogo_tm`, 5 px of
shared ink). Exactly 0 px on all five port screens.

The earlier 24-pair bound was counted at `rest()`, and 10 of the title's 11
overlapping tied pairs are between `ptlogo_back2eff1`..`eff5` -- the five
transient flashes from the settle-time finding, transparent on the settled
screen. A tie between two invisible elements cannot cost a pixel.

Not a knife-edge. Sweeping every keyframe time and every midpoint between
keyframe times, the live-pair count is flat across the ENTIRE settle window:
1 on the EN title, 2 on the JP title, 0 on all four loading bundles -- whose
tie is live only at t17..t33, during the build-in, which matters because
their settle windows are narrow enough to deserve little trust otherwise.

Controls: every entry reporting zero also swaps an overlapping DIFFERENT-key
pair, which must and does move pixels (25 310 / 268 698 / ~765 000 px). Zeros
are explained by shared-ink counts rather than asserted -- the `ptframe` pairs
overlap by bounding box and share 0 px of ink. Entries 0/1/12/15 have NO live
control and their zeros rest on keyframe data rather than a render; recorded
as the weaker claim it is.

Refutation attempt on the corpus's "24 overlapping pairs": it SURVIVES as a
rest-pose count -- an independent recount reproduces entry 7's 16 exactly.
What is overturned is its interpretation as the risk surface.

`tie_break_pixel_cost` gains a settle-time case and an alpha/scale filter on
its rect test; `tie_cost_over_time` is new. Also strips 611 bytes of captured
cargo warnings from the head of the committed tie census.

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

docs/port/HANDOFF.md

@@ -1749,7 +1749,7 @@ here until 2026-08-28 and is now settled.)
 |---|---|---|
 | 🟡 | **cue NAME → event binding** (Q8) | event→**wave** is measured for move/confirm/back; that the cursor's wave is the cue *named* `SE_UI_CURSOR` is still read off the authors' identifiers |
 | ❔ | **the other ~319 SE cues** (Q8) | located one at a time by triggering them; only the three the menu needs have been done |
-| ✅→🟡 | **the paint-order tie-break** (Q3) | ✅ **Its COST is now measured and it is zero on all five port screens** (2026-08-29) — the tied `ptframe` pairs share no ink, and the worst tie-break effect anywhere in `GP_TITLE` is Δ3/255. What stays open is only *why* the game orders ties as it does. Eight candidates refuted. 🔴 **The cost was understated and is corrected 2026-08-29** — the port challenged it and was right. Over all 16 `GP_TITLE` entries: 5 use a **measured** order and carry no tie risk; the other 11 fall back to the derived order and **7 of them have overlapping ties, 24 pairs in total** — 16 of those on the **Japanese title** (entry 7) alone, 2 each on `EXTRAS` EN/JP, 1 each on the four loading bundles. ⚠️ Overlap bounds *where* a wrong tie-break could show; nobody has measured how many actually change a pixel — [`ui-paint-order-derived-check.md`](../re/structures/ui-paint-order-derived-check.md) · [census](../re/data/paint-order-ties-gp_title.txt) |
+| ✅ | **the paint-order tie-break** (Q3) | ✅ **CLOSED 2026-08-29 — the cost is measured and it is one pixel.** At the instant the player sees, the tie-break changes **at most 1 px at Δ1**, on the **Japanese title only**; **exactly 0 px on all five screens you ship**. The previous 24-pair bound was a `rest()` count and survives as such (entry 7's 16 reproduces exactly), but 10 of the title's 11 tied pairs are between `ptlogo_back2eff1`…`eff5` — five transient flashes that are **transparent** on the settled screen. Not a knife-edge: the live-pair count is flat across the whole settle window, and the loading bundles' tie is live only during the build-in (t17–t33). Controls live on every entry reporting zero (a different-key swap moves 25 310 / 268 698 / ~765 000 px); ⚠️ except entries 0/1/12/15, whose zeros rest on keyframe data rather than a render. ❔ *Why* the game orders ties as it does is still unknown — and now costs one pixel — [`ui-tie-break-cost-at-settle.md`](../re/structures/ui-tie-break-cost-at-settle.md) · [cost run](../re/data/tie-break-pixel-cost-gp_title.txt) · [time sweep](../re/data/tie-break-live-over-time-gp_title.txt) |
 | 🟡 | **GamePart ids behind the buttons** (Q4) | the *screens* are measured; the ids are a name match onto the executable's class names |
 | 🟡 | **the boot transitions in code** (Q6) | both levels decoded — phase at `this+132` (`entry→2`, `2→0`, `2→3`, `3→4`, `4→2`) and state at `this+136` inside phase 4. Phase 0 = splash (`LOGO`), phase 2 = title + `PRESS Ⓐ`, phase 4 = menu. Unknown: what the event *numbers* mean |
 | 🟡 | **Ⓑ leaving the main menu** (Q5) | **upgraded 2026-08-29 (later).** The idle half of this objection is **refuted**: the main menu does not self-return for **≥ 60 s** untouched, and the ~8–10 s idle belongs to the **title**. Ⓑ is delivered (Canary logs `vk=5801`) and is the only input in ≥ 100 s before the return, so the **ordering is measured**; the latency is not (a backlogged probe void). The footer point stands — the main menu is still the only screen not advertising Ⓑ — [`menu-navigation-semantics.md`](../re/menu-navigation-semantics.md#-refutation-attempt-2026-08-29--the-main-menus-own-footer-does-not-advertise-ⓑ) |
@@ -1839,3 +1839,34 @@ at that document's own pre-change tag and 14.07 today. Treat conclusions resting
 on it as unverified.
 
 Detail, controls and census: [`docs/re/structures/ui-settle-time.md`](../re/structures/ui-settle-time.md).
+
+## 2026-08-29 (later) — Q3's last open half is closed: the tie-break costs one pixel
+
+✅ **You can stop worrying about the paint-order tie-break.** Its cost is now
+measured rather than bounded, and on the five screens you ship it is **zero
+pixels**. The single non-zero anywhere in `GP_TITLE` is **1 pixel at Δ1** on the
+**Japanese** title, where `ptlogo2` and `ptlogo_tm` share 5 pixels of ink.
+
+**Why the earlier 24-pair figure looked alarming.** It was counted at `rest()`,
+and 10 of the title's 11 overlapping tied pairs are between
+`ptlogo_back2eff1`…`eff5` — the five transient flashes from the settle-time
+finding, which are **transparent on the settled screen**. A tie between two
+invisible elements cannot cost a pixel. The 24 itself is not wrong; it is a
+rest-pose upper bound, and I reproduced its entry-7 component (16) exactly.
+
+**It does not hinge on picking one instant.** Sweeping every keyframe time and
+every midpoint, the number of live tied pairs is **flat across the entire settle
+window** — 1 on the EN title, 2 on the JP title, 0 on all four loading bundles,
+whose tie is live only at t17–t33 during the build-in.
+
+⚠️ **One honest gap:** entries 0, 1, 12 and 15 report zero with **no live
+control** — no overlapping different-key pair is drawn there, so nothing
+demonstrates the renderer would notice a swap on those bundles. Their zeros come
+from the keyframe data (no tied pair has both elements opaque at any instant in
+the window), which is why I state them, but they are a weaker kind of zero than
+the other six.
+
+❔ **Still unknown:** *why* the game orders ties as it does. Eight candidate rules
+remain refuted. This finding does not answer it — it makes it cheap to get wrong.
+
+Detail, controls and reach: [`docs/re/structures/ui-tie-break-cost-at-settle.md`](../re/structures/ui-tie-break-cost-at-settle.md).