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