Withdraw the 16-byte tie record claim: block size is a multiple of 16, not records

The previous commit inferred a 16-byte record from "922 of 922 consecutive block
sizes are a multiple of 16". That inference does not hold, and the claim is
withdrawn rather than softened.

What survives:

- Every one of those 922 blocks opens with a u32 that is positive and a multiple
  of 4, on 922 of 922, ranging 48 to 1744 with 17 distinct values across level
  0's LOD0 blocks. The block opens with a count, not a size and not a pointer.
- Reading that u32 as a byte size and chaining to the next block lands exactly on
  the next block start on 0 of 1383 blocks. Not a size chain.
- Assuming [header][count][count uniform records] and solving for the record size
  gives no answer: no record size tiles the block for any header size up to 512
  bytes. Not 16, not 12, not 8.
- Reading the block as uniform 16-byte units gives fields spanning their entire
  legal range -- u32@0 from -2139029504 to 2139029587, u16@8 and u16@10 both
  0..65535, and 8969 distinct values in i16@0 on level 0. Uniform units would not
  produce that.

So the 16 is a property of the block size, not of a record. The earlier commit
also claimed a record size "on the classes where it can be measured"; those
classes are still correctly identified, but what they measure is the block size.

The strict-increase disproof from two commits ago stands untouched and is what
should have prevented this: the word at +0 was already known not to behave, so
treating 16-byte units as records contradicted a measurement sitting in the same
file. Divisibility is arithmetic; it is not evidence of a record boundary.

Roadmap updated to say block sizes are established and the record layout is not,
with the three measurements that rule the 16-byte reading out.

docs/formats/core-data-regions.md

@@ -1125,16 +1125,36 @@ 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.
 
-**Record size: 16 bytes, on the classes where it can be measured.** The earlier
+**Record size: RETRACTED. Block size is a multiple of 16; the records are not a
+uniform 16 bytes.** 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.
+consecutive block sizes are a multiple of 16. That was taken as evidence for a
+16-byte record. **It is not**, and the record-size claim is withdrawn.
+
+What actually survives, and what killed it:
+
+- Every one of those **922 blocks opens with a `u32` that is positive and a
+  multiple of 4** (922/922), ranging 48 to 1,744 with 17 distinct values across
+  level 0's LOD0 blocks. So the block opens with a count, not a size and not a
+  pointer.
+- Reading that `u32` as a byte size and chaining to the next block lands exactly
+  on the next block start on **0 of 1,383** blocks. It is not a size chain.
+- Assuming `[header][count][count uniform records]` and solving for the record
+  size: **no record size tiles the block for any header size up to 512 bytes.**
+  Not 16, not 12, not 8.
+- Reading the block as uniform 16-byte units gives fields spanning their entire
+  legal range -- `u32@0` from -2,139,029,504 to 2,139,029,587, `u16@8` and
+  `u16@10` both 0..65,535, and 8,969 distinct values in `i16@0` alone on level 0.
+  Uniform units would not produce that.
+
+So the 16 is a property of the **block size**, not of a record. The previous
+commit's "record size is 16 bytes" was an inference from a divisibility fact that
+does not carry it, and it is withdrawn rather than softened.
 
 **`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

docs/roadmap.md

@@ -247,19 +247,20 @@ 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 **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
-      asserts both the disproof and the new bounds so neither can creep back.
+- [~] Tie **block sizes** are established: `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. `packets[0]` reads **256 on 1,864 of
+      1,864** classes and is a constant, not an offset -- `TIE_PACKETS0`. Every
+      one of the 922 blocks opens with a `u32` count, positive and a multiple of
+      4 (48 to 1,744).
+- [ ] The tie **record layout is not decoded, and a 16-byte record is
+      withdrawn.** Block sizes being multiples of 16 does not make the records
+      16 bytes: reading the block as uniform units gives fields spanning their
+      whole legal range (`u32@0` from -2,139,029,504 to 2,139,029,587), and
+      assuming `[header][count][count uniform records]` yields **no record size
+      that tiles the block for any header up to 512 bytes**. The opening `u32`
+      is a count, not a size -- chaining it as one lands on the next block start
+      on 0 of 1,383 blocks.
 - [~] `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: