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.