3717293fa9
Two of my own claims from last iteration die here, and the decode is the thing that kills them. Searching for the SHAPE instead of an assumed count found it immediately: fade words matching 0x??ffffff at alternating strides of 24 and 16, which is a 40-byte block carrying fade at +0 and tint at +24 -- exactly the build layout, starting at +0x68. So "a leaf record's keyframes are not in the build's 40-byte layout" is withdrawn. They are. My scan failed because I demanded 29 strictly-increasing times, having read the word at +0x004 as a keyframe count; the records hold THREE. Decoded, both are horizontal light sweeps. ptloop01 runs pteff03.t32 from x=-639 to x=1521 over t=150..600, which is 450 units or 7.5 s; ptloop02 runs pteff03a.t32 the other way over 570 units or 9.5 s. Which refutes the second thing. Last iteration I attributed the measured 2.2 s oscillation to these elements because build 4 declares them -- association, not evidence. A 7.5 s cycle would give about three peaks in a 22 s capture and I counted eight. So the loops are not what I measured, the 2.2 s stands as a measurement, and its source is now explicitly unidentified rather than wrongly assigned. METHOD gets the general form, because it is what cost the previous iteration: do not hard-code an expected element count into a structure scan. Scan for the shape and let the count fall out.