# 🔴 THE TWO SPLASH ROWS BELOW ARE VOID (retracted 2026-08-30).
# They used `screen render --build 10/11`, which takes a BUILD ORDINAL:
# `screen list` says [10] entry 12, [11] entry 15. Those are the LOADING
# screens. The rows scored loading-screen renders against SPLASH captures.
# I discarded them at the time for a railed gamma fit; the real reason is
# that they were the wrong screens, and the railing was that mismatch
# surfacing in the only place the instrument could report it.
# The `title` row is unaffected -- ordinal 4 is entry 4.
# See splash-settle-window-retraction.txt.
#
# Does UiBuild::settle_time() itself beat rest() against the GAME?
#
# The port ran my PROPOSAL against captures and favoured it 3/3, but tested
# ITS OWN settled pose, not settle_time(). It said so, and that gap is mine.
#
# GEOMETRY, established first: a 1280x720 render matches a 1279x675 capture
# by CROP, not scale --
#     crop rows 0..675        RMSE 14.07
#     resize bilinear         RMSE 68.89
#     crop rows 45..720       RMSE 79.61
#     crop rows 22..697       RMSE 74.92
# The 45-row offset holds for a full 1280x720 DISPLAY frame; these committed
# captures are already the game surface.
#
# Gamma is fitted PER POSE, so each candidate gets its own best case and the
# comparison cannot be won by the fit. Search widened to 0.30..3.00 after the
# first pass railed at a 0.80 floor.
#
# screen     pose      gamma    RMSE     %>8    %>16
# title      settle     0.84    8.17   15.28    3.16
# title      rest       1.04   20.92   70.84   21.14
#            -> SETTLE closer: 15.28 % vs 70.84 % at >8
#
# publisher  settle     0.30   36.38    2.36    2.34  <- RAILED at the search edge; not a fit
# publisher  rest       0.30   36.69    2.74    2.63  <- RAILED at the search edge; not a fit
#            -> SETTLE closer: 2.36 % vs 2.74 % at >8
#
# developer  settle     0.30   33.07    6.16    6.01  <- RAILED at the search edge; not a fit
# developer  rest       0.30   33.42    6.54    6.30  <- RAILED at the search edge; not a fit
#            -> SETTLE closer: 6.16 % vs 6.54 % at >8
#
# ✅ settle_time() beats rest() on all three capture-backed screens, so the
#    IMPLEMENTATION and not just the direction is supported.
#
# ⚠️ ABSOLUTE agreement is poor and much worse than the port's (its title
#    settled row is 0.21 %; mine is an order of magnitude above). My renderer
#    omits things its does not, and a single global gamma is a crude
#    photometric model. Take the ORDERING from this table, not the values.
#
# 🔴 AND ON A WIDER SEARCH (0.30..3.00) THE SPLASHES RAIL AT THE NEW FLOOR TOO.
# A fit that sits on the edge of its range is not a fit -- the photometric model
# is wrong for those two, and with the gamma railed their margins collapse:
#     publisher   settle 2.36 % vs rest 2.74 %   (1.16x)
#     developer   settle 6.16 % vs rest 6.54 %   (1.06x)
# Those two rows DO NOT ADJUDICATE and are not counted.
#
# ✅ ONE SCREEN ADJUDICATES, and it does so decisively. `title` fits at an
# INTERIOR gamma (0.84 settle / 1.04 rest) and gives
#     settle 15.28 %   rest 70.84 %   at >8   -- 4.6x
#     settle RMSE 8.17  rest RMSE 20.92       -- 2.6x
#
# So: settle_time() ITSELF, not merely the direction, beats rest() against the
# game on the one screen where my instrument is valid. The port's three-screen
# result remains the stronger evidence; this closes the gap it named between
# "the port's settled pose" and "UiBuild::settle_time()".