formats: sweep the bundle header - no screen flag, but three of its words decode

The backlog asked what makes a bundle a screen rather than a fragment, and the
obvious suspect was the 32-byte header. Swept over all 2859 composable bundles
with a real declaration table.

The answer to the question is NO, and it is asserted rather than argued: no bit
of the flags word at +0x10 labels a screen. The best any bit manages is bit 13 -
403 bundles, 179 of them carrying a full-screen element, a 44% hit rate against a
12.8% base - and the commonest bit is set on 91% of everything. Enrichment, not a
marker.

The sweep found more than it was asked for, though. The header is not dead space:
+0x18 is 1280 on 2829 bundles and +0x1c is 720 on 2823 - the design resolution at
bundle level, the same pair the parser already reads out of a .rat record, and
asserted here. And +0x04 takes only three values, 0x3C0000 on 2843 and 0x1E0000
on 12, which are exactly 60.0 and 30.0 in 16.16 fixed point, with +0x08 taking
30/1200/120/60 - a frame rate and a duration in frames would fit a format whose
records are keyframe lists. That reading is marked amber: it comes from the
values alone and is not verified against an animation.

Also recorded, since the file will not say: element counts are min 1, median 2,
p75 5, p95 23, max 56, and only 365 bundles carry a full-screen element. The
population is mostly fragments and the separation is shape.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

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

@@ -496,3 +496,49 @@ are byte coincidences in binary data — the scan is unaligned). What those say
 untested. The claims above are about the links a screen's element table can
 reach, which is what a compositor follows; they are not a statement about every
 `opt ` in the file.
+
+## The 32-byte bundle header — swept (2026-08-24)
+
+The backlog asked what makes a bundle a **screen** rather than a fragment, and
+the obvious suspect was the bundle header: six words besides the `RATC` magic and
+the entry count at `0x14`, none of them read by anything. Swept over all **2 859**
+composable bundles with a real declaration table
+(`tests/ui_screen_vs_fragment_disc.rs`):
+
+| offset | distinct values | reading |
+|---|---|---|
+| `+0x04` | **3** — `0x3C0000` ×2 843, `0x1E0000` ×12, `0x3C0001` ×4 | 🟡 **frame rate in 16.16**: `0x3C0000` is exactly `60.0`, `0x1E0000` exactly `30.0` |
+| `+0x08` | 22 — 30, 1200, 120, 60, … | 🟡 a **duration in frames** (0.5 s, 20 s, 2 s, 1 s at 60) |
+| `+0x0c` | 170 | ❔ |
+| `+0x10` | 83 — `0x9400`, `0x9200`, `0x8212`, … | ❔ flags; bit 15 set on **91 %** of all bundles |
+| `+0x18` | **2** — `1280` ×2 829 | ✅ **design width** |
+| `+0x1c` | **3** — `720` ×2 823 | ✅ **design height** |
+
+So the header is not dead space. `+0x18`/`+0x1c` are the design resolution at
+bundle level — the same pair the parser already reads out of a `.rat` record —
+and the two words before the count look like a frame rate and a duration, which
+would fit a format whose records are keyframe lists. 🟡 The rate/duration reading
+is from the **values alone** and is not verified against an animation; the
+resolution one is asserted.
+
+### 🔴 But no bit of it says "screen"
+
+Cross-tabulating every bit of `+0x10` against the two shapes a screen would have:
+
+```
+bundles 2859   with a full-screen (1280x720) element 365   with >=10 elements 464
+bit 15: 2605 set, 347 full-screen      <- set on 91% of everything
+bit 12: 2013 set, 299 full-screen
+bit 13:  403 set, 179 full-screen      <- the best enrichment: 44% vs a 12.8% base
+```
+
+The best any bit manages is **44 %** against a **12.8 %** base, and the most
+common bit is set on nine bundles in ten. That is enrichment, not a label, and
+the test asserts it so a future pass does not re-litigate it from one example.
+
+### What a "screen" looks like, since the file will not say
+
+Element counts over those 2 859 bundles: **min 1, p25 1, median 2, p75 5, p95 23,
+max 56**, and only **365** carry a full-screen element. The population really is
+mostly fragments, and the separation is **shape** — or which bundle references
+which, which the PAK cannot answer directly because its entries are name-hashed.