port: refute my own "the menu residual is the sweeps", and show the narrow windows are harmless

TWO RESULTS, both correcting things I had written.

THE NARROW SETTLE WINDOWS ARE NOT A GAP. Adopting the settle instant left
main_menu and extras on per-element rest() -- windows of 12 units, below the
30-unit bar -- and I recorded that as something left behind. rest() is malformed
only for a TRANSIENT, and the transients are precisely on the screens whose
windows are wide: title (76) has ten, publisher_logo (190) and developer_logos
(145) have one and three, and main_menu and extras have NONE. The discriminator
is returning to dark far before the screen's own end -- ptlogo_back2eff1 is dark
again at t=58 while the title runs to t=269 -- as against the ordinary
fade-in-hold-fade-out every menu element has, where rest at 255 IS the settled
pose. Not claimed as a rule: two screens having narrow windows and no transients
could be coincidence, and n=2 is where I have gone wrong before.

REFUTED, MINE: "the menu residual is localised on the ptloop sweeps", which I
have written twice. It came from reading the BOUNDING BOX, which sat at (441,230)
-- the sweep position. Sweeping the leaf's phase against the live-menu capture:
0.063% at t=60, 0.183% mid-screen at t=350, 0.061% parked at t>=600. With them
parked the box is 834x358 at (445,167) -- the button column, where the focus
signature lives. On extras the same test moves the box (398x295 at the sweep
position, then 736x525 spread) while the magnitude barely changes, 0.192% against
0.200%.

So the box moves with the sweeps and the residual does not. A bounding box over
scattered pixels tells you where the outermost differing pixels are, not where
the difference is -- and I had been quoting it as if it localised a cause.
verify-capture prints that box, so this is a caution about reading my own tool.

And a first piece of evidence on whether the sweeps loop: the disc gives one pass
ending parked off-screen, ORACLE-CAPTURES says they "move continuously" which I
had read as implying a loop, and the idle menu capture matches best with them
OFF-SCREEN. One capture and a weak instrument for an absence, but it is the first
evidence either way and it points against looping.

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

docs/port/DECISIONS.md

@@ -4615,3 +4615,66 @@ unexplained exception in `authored/`.
 **What would change it:** a mechanism in the record, or a gate that measures the
 build-in against a capture. Until then the port is visibly wrong for two frames
 during a build-in nobody compares, which is the cheaper of the two wrongs.
+
+## The narrow settle windows are harmless, and I can now say why
+
+Adopting the settle instant left `main_menu` and `extras` on per-element `rest()`
+— their windows are 12 units, below the 30-unit bar — and I recorded that as a
+gap. **It is not one.** `rest()` is malformed only for a **transient**, and the
+transients are precisely on the screens whose windows are wide:
+
+| screen | window | transients |
+|---|---|---|
+| `title` | 76 | `ptlogo1`/`ptlogo2` ×4, `pteff01`, `ptlogo_back2eff1…5`, `ptlogoall_eff` |
+| `publisher_logo` | 190 | `palogo_sqex_eff` |
+| `developer_logos` | 145 | `palogo_*_eff` ×3 |
+| **`main_menu`** | **12** | **none** |
+| **`extras`** | **12** | **none** |
+
+The discriminator is *returning to dark far before the screen's own end* —
+`ptlogo_back2eff1` is dark again at t=58 while the title runs to t=269 — as
+opposed to the ordinary fade-in-hold-fade-out that every menu element has, where
+`rest` at 255 **is** the settled pose and the final 0 is the exit.
+
+⚠️ **I am not claiming that as a rule.** Two screens having narrow windows *and*
+no transients could be coincidence; it is n = 2, and n = 2 is where I have gone
+wrong before. What it does mean is that **nothing measurable is being left on the
+table by the 30-unit bar today.**
+
+## Refuted, mine — "the menu residual is localised on the `ptloop` sweeps"
+
+I have written that twice. It came from reading the **bounding box** of the
+differing pixels, which sat at (441, 230) — the sweep position. Tested by sweeping
+the leaf's phase against the live-menu captures:
+
+| `main_menu`, sweep phase | differing |
+|---|---|
+| t=60 (barely on screen) | 0.063 % |
+| t=350 (mid-screen) | **0.183 %** |
+| t≥600 (parked off-screen) | **0.061 %** |
+
+✅ Two things fall out. **The capture shows no sweeps**: the port matches best
+when they are off-screen and three times worse when they cross the middle. And
+with them parked the residual's box is **834×358 at (445, 167)** — the *button
+column*, which is where the focus signature lives, not the sweep position.
+
+On `extras` the same test moves the box (398×295 at the sweep position at t=70,
+736×525 spread at t=700) while the **magnitude barely changes: 0.192 % against
+0.200 %**.
+
+🔴 **So the box moves with the sweeps and the residual does not.** A bounding box
+over scattered pixels tells you where the outermost differing pixels are, **not
+where the difference is** — and I had been quoting it as if it localised a cause.
+`verify-capture` prints that box, so this is a caution about reading my own tool.
+
+### And a first piece of evidence on whether the sweeps loop
+
+The disc gives one pass, t=0…600, ending parked off-screen at x=1521.
+`ORACLE-CAPTURES.md` says the title's sweeps *"move continuously"*, which I had
+taken as implying a loop. **The idle main-menu capture matches best with them
+off-screen**, which is evidence they run once and park.
+
+⚠️ One capture, one screen, and "best match" is a weak instrument for an absence
+— but it is the first evidence either way, and it points against looping. The
+loop-length field the Decoder decoded (`+0x08` of a nested record's header) would
+settle it outright; it is not in the pinned tag.