re: the boot splash black gap is ~9 units, measured in draws not luminance

The port found its boot had no black frame between the publisher and developer
splashes and authored 12 units by analogy with the menus' transition quad. On
the boot path that analogy has nothing behind it -- palogo_eff0.prm is a single
static keyframe, so the splash bundles declare no fade quad.

I had agreed with the dismissal that hid the defect: told the residual was
0.03 s against a bound built from two measured ranges plus jitter slack, I said
it said more about the bound than the game. The real gap was 0.2 s.

Measured in the draw stream, which separates true black from a fade tail where
luminance cannot: palogo_sqex is drawn to frame 125 at alpha 7, frames 126-129
submit NO sprite quad at all, and the developer fades in at frame 130 from
alpha 34. Four presented frames, the only such run in the sequence.

Converted with the disc as its own clock rather than a frame rate -- this run
presented at 13.1 fps against 28 elsewhere -- palogo_sqex declares alpha >= 1
for 239.8 units and is drawn in 105 frames, giving 2.284 units per presented
frame, which the title capture independently corroborates at 2.231. So the gap
is ~9.1 units (0.152 s), against the 12 authored; +-1 frame is 6.9-11.4. And
the true black is SHORTER, since both boundary frames still carry picture.

Second finding: the developer splash is ONE composited 525x259 quad at the
bounding box of its three declared logos, none of whose individual sizes is
ever submitted. That is why an earlier pass reported "developer splash: 0
frames".

Declaration sites ruled out: the splash bundles (no fade quad) and the
top-level +0x08 (a family constant, 300/60, slack 12-226 units). The
executable is NOT looked at and is named as the next place rather than
claimed.

Also answers the port's sweep question: +0x08 canNOT settle it, because
ptloop01/ptloop02 have zero slack and a zero-slack record cannot distinguish
"loops" from "runs once and stops". The oracle settles it for the TITLE -- the
sweep oscillates over its whole range and resets hard to the same start, once
in dwell 1 and twice in dwell 2, so it does not park. The MENU is unmeasured
and stays open.

Tooling: GRACE and NOTAP knobs for ui_draw_capture.sh. The script taps A on
"the screen changed a lot", which is also true of a fading splash -- a first
run tapped through the publisher and the developer never appeared. The
instrument was perturbing what it measured.

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

docs/re/structures/ui-record-loop-length.md

@@ -121,6 +121,35 @@ visible in the draw stream as the frames where the game submits no draw at all.
   hold; it is what a four-sample wall-clock measurement of a ~2 s period in this
   emulator looks like.
 
+## ❔ What this field does NOT settle: do the `ptloop` sweeps loop?
+
+Asked by the port, hoping `+0x08` would decide it. **It does not.**
+
+`ptloop01.rat` declares `+0x08` = **600** with keyframes reaching exactly t=600;
+`ptloop02.rat` declares **720**, keyframes to t=720. **Slack zero** — and a
+zero-slack record is precisely the case this field cannot discriminate: "loops at
+600" and "runs once for 600 and stops" produce the identical header. 92.3 % of
+records on the disc are in that state.
+
+✅ **The oracle answers it for the title, and the answer is that they keep
+moving.** Tracking the sweep quad across two title dwells in a draw capture:
+
+| | sweep draws | x range (NDC) | backward jumps to the start |
+|---|---|---|---|
+| title dwell 1 (frames 138–1220) | 1008 | −3.02 … −0.33 | **1** (frame 1161) |
+| title dwell 2 (frames 5963–7025) | 908 | −3.02 … +0.42 | **2** (frames 6370, 6822) |
+
+The x position oscillates across the whole range for the entire dwell and resets
+hard to the same start value (−2.38). A run-once-and-park would show one traverse
+and then a constant x. **It does not park.**
+
+⚠️ **This is the TITLE, and the port asked about the MAIN MENU.** Both declare
+`ptloop01`/`ptloop02` with the same 600/720, but I have not captured the menu, and
+the port's own evidence — an idle menu capture matching best with the sweeps
+off-screen — points the other way. Either the menu's sweeps behave differently, or
+"best match" is doing badly at detecting an absence, which the port said itself.
+**Unresolved for the menu; measured for the title.**
+
 ## Reach
 
 ⚠️ **This says where a cycle ends, not that every record cycles.** 92.3 % of