re: the loop record is located, its cycle is still not readable

Continuing the one gap from last iteration -- turning the title's
measured 2.2 s loop into a decoded cycle. It did not turn.

The record itself is found and partly confirmed. ptloop01.rat is an
opt-linked leaf RATC at 0xbb5966 in build 4, placing pteff03.t32, with
0x1e -- thirty -- in the high half of the word at +0x004, which is the
~30 keyframes ui-rat-layout.md predicts for a loop record. Its pivot
fields read 200 and 90, matching exactly what screen info prints for
ptloop01, so this is the right blob and the header offsets hold.

The times are not there. A build's keyframes are 40-byte blocks with the
time at +36; scanning every 4-byte-aligned start across a 0xC0 window for
29 strictly increasing values at that stride finds nothing, in either
loop record. So a leaf record's keyframe layout is NOT the build
placement layout, which is now a line in REFUTED because it is the
obvious first assumption and it is wrong.

The 2.2 s stays measured and the port hardcodes it. What the next attempt
inherits is the record's address, a confirmed pivot, and one layout ruled
out -- which is the useful part of a negative.

docs/re/REFUTED.md

@@ -35,6 +35,10 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "a `.rat` leaf record's keyframes use the build's 40-byte placement-block
+  layout (time at `+36`)" → they do not. A strided monotonic scan over
+  `ptloop01.rat`/`ptloop02.rat` finds no increasing time sequence at any aligned
+  start. [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the developer splash cannot be rendered by `screen render` at all" → it can,
   with **`--all`**. It is only invisible to the *default* listing, which filters on
   `is_build`. [`ui-title-build-map.md`](ui-title-build-map.md)

docs/re/ui-title-build-map.md

@@ -220,10 +220,33 @@ composition ([`INDEX.md`](INDEX.md), UI screen layout row). So the title carries
 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.
+### ❔ The loop record was opened, and its cycle is still not readable
+
+The `.rat` was located and partly confirmed, but its **keyframe times are not**.
+
+`ptloop01.rat` is an **`opt `-linked leaf record**, not a nested build: in build 4
+the chunk `opt ` (size `0x0c`) carries the name `ptloop01.rat`, immediately
+followed by a `RATC` blob at **`0xbb5966`**. `ptloop02.rat` is the same shape at
+`0xbb5a82`.
+
+| offset | value | |
+|---|---|---|
+| `+0x004` | `0x001e0000` — **30** in the high half | the ~30 keyframes [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md) predicts |
+| `+0x014` | `1` | name count |
+| `+0x018` / `+0x01c` | `1280` / `720` | design space |
+| `+0x020` | `pteff03.t32` (`pteff03a.t32` for loop02) | the sprite it places |
+| `+0x050` / `+0x054` | `200` / `90` | pivot — **matches `screen info`'s `pivot (200,90)` for `ptloop01`**, which confirms this is the right record |
+
+**But the times are not where a build's are.** A build's keyframes are 40-byte
+blocks with the time at `+36`. Scanning every 4-byte-aligned start across
+`+0x60 … +0x120` for 29 strictly-increasing values at a 40-byte stride finds
+**nothing**, in either record. So a leaf record's keyframe layout is *not* the
+build placement layout, and the loop's declared cycle cannot be read by that
+route.
+
+**The ≈ 2.2 s therefore stays measured, not decoded.** What a future attempt
+gains from this one is the record's address, the confirmed pivot, and one layout
+ruled out.
 
 **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.