a048910497
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.