port: the menus' residual is the tone floor, and extras is not really 3x worse

extras sits at 0.19% differing against main_menu's 0.06%, on two screens of the
same family. The signed difference explains it: both are uniformly +9 to +12
brighter in the dark outer columns, in nearly identical patterns (+12.13/+12.29
against +11.63/+11.03 at x=0; +10.60/+9.05 against +10.24/+8.84 at x=960). That
is the transfer curve -- gamma > 1 in the darks -- with no dipole, no
displacement and no missing element.

So the 0.06/0.19 gap is not a difference in fidelity. The thresholded count only
sees pixels differing by more than 64 levels, which are text and sprite EDGES,
and the two screens have different amounts of high-contrast edge. The level
disagreement, which is what a tone term produces, is the same on both. I had
taken the ratio of two counts as meaningful -- the bounding-box lesson in a
different costume.

A DIAGNOSTIC TRAP OF MY OWN: the first pass reported 10 of 18 elements
"transparent at rest" on extras -- the buttons, the title, the frames -- and
looked exactly like a missing-element bug. `--screen=NAME` without `--time`
renders at t=0, and pose_at clamps t to minf(t, settle_units), so t=0 stays t=0.
With --time=2.0 it draws 18 of 18. The tool was right and my invocation was
wrong, and it reported a WORSE problem than existed, which wastes an iteration
rather than hiding one.

REFUTATION ATTEMPT, SURVIVED: the Decoder's 239.8 units for palogo_sqex's alpha
>= 1 span, which is the denominator of the units-per-frame conversion behind the
9-unit black hold I just authored. Computed independently from my export under
the linear ramp the port already uses: alpha first reaches 1 at t=15.0588 and
last exceeds it at t=254.8750, giving 239.816 units. Agrees to four significant
figures, from different sides of the same record -- which is what makes that
constant safe to hold.

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

docs/port/DECISIONS.md

@@ -4758,3 +4758,66 @@ weak evidence points the other way there — sweeping the phase against
 (0.061 %) and three times worse mid-screen (0.183 %), and if they looped the
 sweep is on screen for roughly 73 % of the cycle. **Two weak signals in opposite
 directions is a reason to scope, not to pick.**
+
+## The menus' residual is the tone floor, not structure — and `extras` is not really 3× worse
+
+`extras` sits at 0.19 % differing against `main_menu`'s 0.06 %, on two screens of
+the same family, and that gap wanted explaining.
+
+**Signed difference (port − capture), by cell:**
+
+| | x=0 | x=320 | x=640 | x=960 |
+|---|---|---|---|---|
+| `extras` y=169 | **+12.13** | −3.64 | +2.43 | **+10.60** |
+| `extras` y=338 | **+12.29** | +1.36 | +1.42 | **+9.05** |
+| `main_menu` y=169 | **+11.63** | −0.68 | +3.01 | **+10.24** |
+| `main_menu` y=338 | **+11.03** | +3.93 | +2.92 | **+8.84** |
+
+**The two screens are nearly identical**, and the port is uniformly **+9 to +12
+brighter in the dark outer columns** — which is exactly the transfer curve I
+measured earlier: γ > 1 in the darks, capture darker than render. There is no
+dipole, no displacement, no missing element.
+
+So the 0.06 % / 0.19 % gap is **not a difference in fidelity**. The thresholded
+count only sees pixels differing by more than 64 levels, which are text and
+sprite **edges**; the two screens simply have different amounts of high-contrast
+edge. The *level* disagreement, which is what a tone term produces, is the same
+on both.
+
+⚠️ **This is the bounding-box lesson again in a different costume.** I had two
+numbers, 0.06 and 0.19, and took the ratio as meaningful. It is a count of
+threshold crossings, and a count of threshold crossings is not a measure of how
+wrong a screen is.
+
+### A diagnostic trap of my own, worth writing down
+
+My first pass at this reported **10 of 18 elements "transparent at rest"** on
+`extras` — the buttons, the title, the frames — and looked exactly like a
+missing-element bug. It was not. **`--screen=NAME` without `--time` renders at
+t = 0**, and `pose_at` clamps `t` to `minf(t, settle_units)`, so t=0 stays t=0 and
+every element is still at its first keyframe. Passing `--time=2.0` draws 18 of 18.
+
+The tool was right and my invocation was wrong, and the failure looked like a
+serious defect rather than an empty argument. Same family as the instrument traps
+this session has collected — and mine was the one that reported a *worse* problem
+than existed, which is the direction that wastes an iteration rather than hiding
+one.
+
+## Refutation attempt — their 239.8-unit figure, checked from my export
+
+The Decoder converted the boot's black gap using the disc as its own clock:
+*"`palogo_sqex` declares alpha ≥ 1 for **239.8 units** and is drawn in 105 frames
+→ 2.284 units/frame."* That 239.8 comes from their reading of the record; I have
+the same element in my export and can compute it independently.
+
+`palogo_sqex` ramps 0 → 255 over t=15…30 and 32 → 0 over t=251…255. Under the
+linear ramp the port already uses, alpha first reaches 1 at **t = 15.0588** and
+last exceeds it at **t = 254.8750**:
+
+**239.816 units.**
+
+✅ **Survives, to four significant figures.** It matters more than a spot-check:
+that number is the *denominator* of the units-per-frame conversion behind the
+9-unit black hold I just authored, so an error in it would have propagated
+straight into a constant I ship. Two derivations from different sides of the same
+record agreeing to 0.02 % is what makes that constant safe to hold.