Establish the 16-byte tie record on measurable classes; packets[0] is a constant

The previous commit reported "3580 non-empty LOD blocks compute as divisible by
16" and then said the figure should not be trusted, because it came from the
"next packets offset ends this block" rule. That rule is unsound: packets is
strictly increasing on only 461 of 1864 classes. On the other 1403 the two
offsets are unordered and cannot both be block starts into one ascending region.

Restricting to the 461 classes where the rule does hold, 922 of 922 consecutive
block sizes are a multiple of 16. That is the evidence for a 16-byte record, and
it is now scoped to the subset where it can be checked rather than claimed over
all 1864. The other 1403 are unmeasured, not measured-and-different.

packets[0] is a constant, not an offset: it reads 256 on 1864 of 1864 classes,
while packets[1] and packets[2] vary widely and land at different addresses in
core_data on every class. Read as a block start, 256 points just past the
0x48-byte header -- which is how it was being used, and exactly how a field gets
mistaken for a pointer. It is now TIE_PACKETS0 and nothing depends on it.

Still not decoded: what the 16 bytes hold. i16[0] at +4 takes 8969 distinct
values on level 0 and is not the two-valued field a 12-unit sample suggested; the
word at +0 is not a run offset.

The test pins all four numbers -- packets[0] constant, the 922/922 divisibility,
the 461/1864 ordering, and the 0/1864 monotonic disproof -- and asserts that the
ordering is *not* universal, so a future change there fails loudly instead of
quietly invalidating the record size.

docs/formats/core-data-regions.md

@@ -1125,6 +1125,24 @@ The sample was twelve units out of 1,724,334. Both the monotonic reading and the
 quantisation were artifacts of that sample, and the disproof is asserted in
 `crates/gc-extract/tests/disc.rs` so it cannot creep back.
 
-**Not established:** the block's record size. 3,580 non-empty LOD blocks compute
-as divisible by 16, but some `packets` offsets run backwards, so the "next offset
-delimits this block" end is wrong for them and the figure should not be trusted.
+**Record size: 16 bytes, on the classes where it can be measured.** The earlier
+"divisible by 16" figure was computed from the "next `packets` offset ends this
+block" rule, which is unsound because **`packets` is strictly increasing on only
+461 of 1,864 classes**. On the other 1,403 the two offsets are unordered, so they
+cannot both be block starts into one ascending region.
+
+Restricting to the 461 classes where the rule does hold: **922 of 922**
+consecutive block sizes are a multiple of 16. That is the evidence for a 16-byte
+record, and it is confined to the subset where it can be checked. The other 1,403
+classes remain unmeasured rather than measured-and-different.
+
+**`packets[0]` is a constant, not an offset.** It reads **256 on 1,864 of 1,864**
+classes, while `packets[1]` and `packets[2]` vary widely and land at different
+addresses in `core_data` on every class. Read as a block start, 256 points just
+past the 0x48-byte header -- which is exactly how it was being used, and exactly
+the kind of field that gets mistaken for a pointer. It is now
+`TIE_PACKETS0` and nothing depends on it.
+
+**Still not decoded:** what the 16 bytes hold. `i16[0]` at `+4` takes 8,969
+distinct values on level 0 and is not the two-valued field a 12-unit sample
+suggested; the word at `+0` is not a run offset.

docs/roadmap.md

@@ -247,15 +247,19 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       despite the field name). All **1,864** tie classes resolve, with
       `o_class` agreeing on every one, and all **5,592** LOD block offsets land
       inside `core_data`.
-- [ ] The tie **block layout is not decoded.** LOD0 blocks are not a uniform
-      stride of records: 3,580 non-empty blocks compute as divisible by 16,
-      but that figure is not trustworthy because some `packets` offsets run
-      backwards, so the "next offset" end is wrong for them. One reading is
-      **disproved**: the word at `+0` of a 16-byte unit is strictly increasing
-      on **0 of 1,864** blocks, despite looking exactly like a linked list on
-      the first twelve units of one class. A 12-unit sample of a 1.7M-unit
+- [~] The tie **record size is 16 bytes**, established on the classes where it can
+      be checked: `packets` is strictly increasing on only **461 of 1,864**
+      classes, and on those **922 of 922** consecutive block sizes are a multiple
+      of 16. The remaining 1,403 classes are unmeasured, not measured-and-
+      different. `packets[0]` reads **256 on 1,864 of 1,864** classes and is a
+      constant, not an offset -- `TIE_PACKETS0`.
+- [ ] The tie **record contents are not decoded.** One reading is **disproved**:
+      the word at `+0` of a 16-byte unit is strictly increasing on **0 of 1,864**
+      blocks, despite looking exactly like a linked list on the first twelve
+      units of one class, and `i16[0]` takes 8,969 distinct values on level 0
+      rather than the two a sample suggested. A 12-unit sample of a 1.7M-unit
       population is the pooled-claim error rule 3a exists to prevent; the test
-      now asserts the disproof so it cannot creep back.
+      asserts both the disproof and the new bounds so neither can creep back.
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at
       32 still gives 231 sane-looking entries of 358, which is the hazard).
       Geometry header parsed and checked field by field on all 358 spans: