re: the RATC +0x0c interval is authored, not a keyframe extent

Tested the alternative I recorded last iteration. Parsing every bundle's
keyframe times (2985/2985 parse), the derived-summary reading -- (high,low) ==
(min,max) keyframe time -- holds in 6 of 2985 (0.2%).

The apparent 34.2% match on 'high == min' is a coincidence of zeros: the minimum
keyframe time is 0 in 96% of bundles and high is 0 in 34.9%, so the 1022
'matches' are exactly the both-zero cases. Worth noting that last iteration I
declined to treat the high==0 share as support -- it turned out to be the
confound rather than the signal.

The interval is also narrow: (low-high)/(max-min) has a median of 0.019, about
2% of the keyframe span. It lies inside the keyframe range in 88.6%, entirely
after in 174 and entirely before in 68.

A short authored window is not the shape of a playback range or a whole-animation
loop region, so those readings weaken too. What it is stays open.

docs/re/BACKLOG.md

@@ -305,8 +305,10 @@ See [`structures/ui-composable-bundles.md`](structures/ui-composable-bundles.md)
   the only supporting evidence is that the twelve 30.0 bundles cap at `+0x08`=30
   while the 2 843 60.0 ones reach 1 440. ✅ `+0x0c` is **two u16s forming an ordered
   interval** — `high < low` in **2 985/2 985**, both bounded by the animation
-  length; 🟡 which interval, and ❔ whether it is authored or just the keyframe
-  min/max, is untested. `+0x10` still ❔.
+  length; ✅ it is **authored, not the keyframe min/max** — that
+  reading holds in 6 of 2 985 (0.2 %), and the apparent 34 % match on `high` is a
+  coincidence of zeros. The window is narrow, a median 2 % of the keyframe span.
+  🟡 what the window means stays open. `+0x10` still ❔.
   See [`structures/ui-rat-layout.md`](structures/ui-rat-layout.md).
 * 🟡 **What `opt ` links — a record→record reference** (2026-08-24, measured
   disc-wide and asserted). All **1 467** links reachable from a declaration table

docs/re/structures/ui-rat-layout.md

@@ -629,14 +629,36 @@ the field being flags or a packed count.
 active window all fit an ordered pair inside the animation, and nothing measured
 here separates them.
 
-❔ **The alternative I have not ruled out** is the obvious one: that
-`(high, low)` is simply the **minimum and maximum keyframe time** in the bundle,
-which would make it a derived summary rather than an authored range. That is
-testable and I did not test it — it needs the keyframe times parsed per bundle,
-which the `ui_layout` reader can do. **First step**: for each bundle, compare
-`(high, low)` against `(min, max)` of its keyframe times. If they match, the
-field is a cached extent; if `high` is often 0 where the first keyframe is not,
-it is authored. The 34.9 % of bundles with `high == 0` is suggestive of the
-latter but is not evidence on its own.
+### ❌ The derived-summary reading is refuted — the interval is authored
+
+Tested as promised, by parsing every bundle's keyframe times (all **2 985**
+parse) and comparing against `(high, low)`:
+
+| | |
+|---|---|
+| `high == min` keyframe time | 1 022 (34.2 %) |
+| `low == max` keyframe time | **6 (0.2 %)** |
+| **both** — the derived reading | **6 (0.2 %)** |
+
+**And the 34.2 % is a coincidence of zeros.** The minimum keyframe time is 0 in
+**96 %** of bundles, and `high` is 0 in 34.9 % — the 1 022 "matches" are exactly
+the cases where both are zero. It is not evidence of anything. (This is why the
+`high == 0` share was worth *not* treating as support last iteration: it turned
+out to be the confound, not the signal.)
+
+So `(high, low)` is **authored, not derived**. It is also *narrow*: the ratio
+`(low − high) / (max − min)` has a **median of 0.019** — the interval typically
+covers about **2 %** of the bundle's keyframe span.
+
+Where it sits relative to the animation:
+
+    inside the keyframe range          2 645  (88.6 %)
+    entirely after the last keyframe     174
+    entirely before the first             68
+
+A short authored window, usually inside the animation but not always, is not the
+shape of a playback range or a loop region over the whole animation. 🟡 What it
+*is* remains open; what is now excluded is that it is a cached extent of the
+keyframes.
 
 `+0x10` is untouched by this and remains ❔.