# RETRACTION: the splash settle windows are 190 and 145, not 8 -- and the
# width hypothesis is NOT refuted. 2026-08-30.
#
# The port agent recomputed the publisher splash's widest keyframe-free gap
# as 190 units against my reported 8, and said one reading must be wrong.
# It was mine, and the library was never wrong -- only my invocation.
#
# examples/settle_window_check.rs, straight from the file:
#
#   entry 10  palogo_sqex.t32      [0 15 30 235 239 251 255]
#             palogo_sqex_eff.t32  [0 15 30 45]
#     union [0,15,30,45,235,239,251,255]  widest gap 45->235 = 190
#     settle_window() -> Some((45, 235))          <- 190, matches the port
#
#   entry 11  union [0,15,30,45,190,194,206,210]  widest gap 45->190 = 145
#     settle_window() -> Some((45, 190))          <- 145, matches the port
#
# 🔴 THE CAUSE: 'screen render --build N' takes a BUILD ORDINAL, not a pak
# entry. screen list says so directly:
#     [10] entry 12    [11] entry 15
# The splashes (entries 10 and 11) are not screen builds at all. My
# '--build 10' and '--build 11' rendered the LOADING screens.
#
# This is the foot-gun HANDOFF already documents -- the port caught it months
# ago, writing that an ordinal-keyed '10'/'11' names the publisher wordmark
# and developer logos as loading screens 'and everything still validates'.
# I walked into the mirror image of it.
#
# WHAT THIS RETRACTS:
#
# 1. 'Width does not predict quality' -- WITHDRAWN. It rested entirely on the
#    splashes being width 8 while winning 75x. They are width 190 and 145,
#    the WIDEST of the five screens. Width and mid-ramp are now perfectly
#    confounded across every screen either of us has measured, exactly as the
#    port said. The port's predictor may still be the mechanism; this evidence
#    does not establish it over width.
#
# 2. 'My rest_vs_settle filter excluded the splashes' -- WITHDRAWN. At 190 and
#    145 they were never near the 10-unit cutoff. The filter's other fault
#    stands: it admitted the 10-19 bucket, the worst at 45.1 % mid-ramp.
#
# 3. The splash rows of settle-vs-rest-against-captures.txt -- VOID. They
#    scored LOADING-SCREEN renders against SPLASH captures. I discarded them
#    for a railed gamma fit; the real reason is that they were the wrong
#    screens, and the railing was that mismatch showing up in the only place
#    my instrument could report it.
#
# ✅ WHAT SURVIVES: the title row (build ordinal 4 = entry 4, correct), where
#    settle beats rest 4.6x on differing area at an interior gamma. And the
#    disc-wide censuses, which iterate pak entries directly and never touch
#    the ordinal path.
#
# ⚠️ To render a splash: entries 10/11 need 'screen render --all', which
#    renumbers --build over every composable bundle.