Two class-header words are base-relative offsets pointing past the tie packets

Chasing where the AD-GIF is, since f43a1c2 established it is not in the packet.
Two of the undecoded class-header words are offsets.

base + 0x1c and base + 0x34 land inside core_data on 1,864 of 1,864 classes, so
both are relative to the class base rather than absolute, and both are non-zero
on every class. Both also land **past** that class's own tie packet blocks on
every class, so they address per-class data held elsewhere in core_data rather
than the tie geometry.

That is consistent with f43a1c2: if the packet's own control region is not a tag
stream, the per-class draw state is referenced from somewhere else.

WHAT IS THERE, AND WHAT IS NOT CLAIMED

The bytes are structured, not random -- class 3 shows a fixed-stride table with
`80 01 00` recurring, class 2's field is a monotone byte table, class 5's has
`38 38 38` and `ff 00 ff ff`. They read like compiled shader programs with
small-integer parameters, or lookup tables.

**Not identified, and deliberately not named.** None of those three fragments has
been run against a control, and all three were picked because they looked like
something. That is precisely the finding rule 4 refuses, and having spent this
session on four retractions I would rather record an honest "structured,
unidentified" than a plausible format that has not earned it. If any of these
turns out to be a shader program the next step is a control, not a better-looking
hex dump.

ALSO SETTLED

0x24 is demonstrably not an offset: only 17 of 1,864 of its values land in range
for core_data. Recorded as packed data. 0x28, 0x2c, 0x38 remain high-entropy and
unexplained.

281 passing with the disc present (23 + 19 + 61 + 156 + 22), clippy clean.

docs/plan/level-assets.md

@@ -1849,3 +1849,41 @@ vertices, scissor. `bfc_distance` is a per-record quantity relating to the shade
 count whose meaning is not established, and the "quadwords of ad-gif data" reading
 of it is wrong. The field doc said so in terms before this measurement; it does
 not now.
+
+
+## Where the AD-GIF is not: class-header offsets 0x1c and 0x34
+
+Two words in the class header's undecoded tail are offsets, and they are the
+best remaining lead on the AD-GIF.
+
+`base + 0x1c` and `base + 0x34` land inside `core_data` on **1,864 of 1,864
+classes**, so both are relative to the class base rather than absolute, and both
+are non-zero on every class. And both land **past** that class's own tie packet
+blocks on every class -- they address per-class data stored somewhere else in
+core_data, not the tie geometry.
+
+What is there is structured, not random. Class 0 at 0x1c:
+
+    54 5d 5f 0c  44 44 44 01  03 11 19 00  1c 00 60 0a  30 08 60 0a
+    ff 00 ff ff  20 0c 50 02  44 38 2b 50
+
+and class 3 at the same field:
+
+    20 05 c5 00  00 80 01 00  26 05 cb 00  21 88 01 00  2c 05 c0 00
+    00 80 01 00  32 05 c0 00  00 80 01 00
+
+Class 3 is a fixed-stride table with `80 01 00` recurring. Class 5's 0x34 field
+has `38 38 38` and `ff 00 ff ff`. Class 2's 0x1c field is a monotone byte table:
+`26 27 0e 0f 10 11 12 13 24 25 15 1e 17 1f 14 15 16 17 20 21 22 23`.
+
+These read like compiled shader programs with small-integer parameters, or as
+lookup tables. **They are not identified**, and the resemblance to anything
+specific is exactly the kind of finding rule 4 exists to refuse -- none of these
+three fragments has been shown to beat a control, and they were picked because
+they looked like something.
+
+What is established is structural: two base-relative offsets, always in range,
+always past the tie packets, pointing at repeated structured records rather than
+DMA tags. That is consistent with the earlier finding that the packet's own
+control region is not a tag stream -- the game's per-class draw state is stored
+elsewhere and referenced, not inlined.