re: the title loops at about 2.2 s -- and the build-in test I intended

did not work

I set out to do for the title what worked for the splash: measure the
build-in and check it against the declared keyframes. That part failed,
and I am recording the failure rather than the number.

It failed for two reasons, both mine. The title was reached by skipping
the movie with A, which cuts to black and brings the title up on a path
that may not be the normal one. And the visible rise, about 2.7 s, is a
luminance curve -- which screen-transitions.md already establishes is not
the fade quad's ramp. So 2.7 s neither confirms nor contradicts build 4's
declared 16 -> 261, four point oh eight seconds. They are not measuring
the same thing, and I have said so instead of reporting a discrepancy.

What the recording did establish is worth having anyway: the title never
settles. Over 22 s the mean luminance oscillates continuously, peaks at
5.6, 7.8, 10.0, 12.7, 15.2, 17.1, 19.2 and 21.3 s, mean interval 2.24 s.
Marked as about 2.2 s plus or minus 0.4 rather than a precise period,
because peak-picking a low-amplitude signal is coarse.

The mechanism was already decoded and I did not re-derive it: build 4
declares ptloop01.rat and ptloop02.rat, and loop*.rat is a looping sprite
animation rather than a composition. What is new is the period, and that
it runs forever. For the port that matters -- drawing the resting pose
and stopping will look wrong.

Not confirmed, and flagged: that 2.2 s is the loop's OWN declared cycle.
screen info prints the element's placement keyframes but not the frame
count inside the .rat, and I did not open it.

docs/port/HANDOFF.md

@@ -61,6 +61,13 @@ authored version can be deleted.
   this milestone changes — every screen in scope is `GP_TITLE` — but do not ship
   `kind == 0x3002` as a general button test.
   (The kind is the 4th `u32` of the 60-byte declaration entry, at `+40`.)
+* **The title screen loops — it is not a still.** After building in, mean
+  luminance oscillates continuously at **≈ 2.2 s ± 0.4** (measured, 7 intervals
+  over a 22 s capture). Build 4 declares `ptloop01.rat`/`ptloop02.rat`, and
+  `loop*.rat` is a decoded **looping sprite animation**. Drawing the resting
+  pose and stopping will look wrong. ❔ Whether 2.2 s is the loop's declared
+  cycle is unread — `screen info` does not print the frame count inside a
+  `.rat`.
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
   ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
   disc's real navigation structure is unknown, and `opt ` is *not* a focus link