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/re/ui-title-build-map.md

@@ -199,3 +199,44 @@ tools/re-capture/pad.py tap A 0.30
 ```
 
 Mind the d-pad hold — see [`METHOD.md`](METHOD.md).
+
+## ✅ The title is not a still image — it loops, ≈ 2.2 s
+
+Recording the title at 10 fps for 22 s shows the screen **never settles**. After
+the build-in it oscillates by about ±0.5 in mean luminance, continuously:
+
+```
+peaks at   5.6  7.8  10.0  12.7  15.2  17.1  19.2  21.3 s
+intervals  2.2  2.2   2.7   2.5   1.9   2.1   2.1
+                                       mean 2.24 s
+```
+
+**measured**, n = 7 intervals, spread 1.9–2.7 s — peak-picking a low-amplitude
+signal is coarse, so read it as **≈ 2.2 s ± 0.4**, not a precise period.
+
+The mechanism is already decoded: build 4 declares **`ptloop01.rat` /
+`ptloop02.rat`**, and `loop*.rat` is a **looping sprite animation** rather than a
+composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries a
+looping element by construction; what is new is that it runs at ≈ 2.2 s and never
+stops.
+
+❔ **Not confirmed:** that 2.2 s equals the loop's own declared cycle. `screen
+info` prints the element's *placement* keyframes (`ptloop01` is
+`[70 100 238 250]`) but not the frame count inside the `.rat`, and I did not open
+it. So the period is measured, not read.
+
+**For the port:** drawing build 4's resting pose and stopping will look wrong —
+the title has a continuous ≈ 2.2 s loop over it.
+
+### ❔ The declared 4.08 s build-in was not tested
+
+That was the intent of this recording and it did not work. The title was reached
+by **skipping the movie with Ⓐ**, which cuts to black and brings the title up on a
+path that may not be the normal one; and the visible rise (≈ 2.7 s, from t ≈ 0.8
+to 3.5) is a *luminance* curve, which
+[`screen-transitions.md`](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` (4.08 s); the two are not measuring the same thing.
+
+Testing it properly needs the title reached **without** a skip, and a way to
+separate the quad from the elements — neither of which this recording had.