Rule out a count field in chunk record bodies; correct a six-record impression

With the record framing settled (leading two bytes = record index), the body is
bytes 2..len. Four probes, mostly negative, recorded so the next attempt does not
repeat them.

No count field. For every chunk type, every u16 and u32 position in the first 64
body bytes, at element strides 1,2,3,4,6,8,12,16: does the stored value equal
(record_len - offset) / stride on 90%+ of records? No type produced a hit. The
record does not carry an element count near its head.

The body is dense, not float-dominated. For the largest type (2430 records,
326-byte bodies): f32 reads within +/-5000 of origin 74%, uniform-random control
49%, zero-byte fraction 13%. Above baseline but far short of the tie blocks
(53-64% against 16%, with 43% zero bytes).

There is an index-like region near the tail. In the largest type, 12 of 163 u16
slots have a maximum below 0x1000 -- too small for float or half-float, so those
look like indices or small counts -- clustered at slots 111-121 and 130-131.

A sample-size correction. Dumping six records of one chunk showed slots 112-119
zero on every record plus a long run of other constants, which reads as "the
record is mostly a per-chunk template". Measured across the 1,171 chunks with at
least 8 records: 15,422 of 164,390 u16 slots are constant across their chunk,
9.4%, and 0 of 1,171 chunks are entirely constant.

So 9.4%, and no chunk is a template. Six records looked like a majority because
that chunk's tail carries shared constants. Per type the figure ranges from 9.4%
overall to 55.6% on one type, so it is reported per type as well as pooled --
the pooled figure alone would hide that spread, which is the same trap rule 3a
describes.

docs/formats/core-data-regions.md

@@ -1385,3 +1385,45 @@ and it also disagreed with `bucket_rule` on the byte-0 count (1,208 against
 Recorded because the two numbers came from the same run and only the discrepancy
 exposed the probe as wrong. The lesson is narrow and worth stating: when a
 one-off probe and a committed helper disagree, check the probe first.
+
+## Chunk record bodies: what was ruled out
+
+With the framing settled (leading two bytes = record index), the body is bytes
+`2..len`. Four probes on it, mostly negative.
+
+**No count field.** For every chunk type, every `u16` and `u32` position in the
+first 64 body bytes, at element strides 1, 2, 3, 4, 6, 8, 12 and 16: does the
+stored value equal `(record_len - offset) / stride` on 90% or more of records?
+**No type produced a hit.** The record does not carry an element count near its
+head.
+
+**The body is dense, not float-dominated.** For the largest type (2,430 records,
+326-byte bodies):
+
+    f32 reads within +/-5000 of origin : 74%
+    uniform-random control              : 49%
+    zero-byte fraction                  : 13%
+
+Above baseline but far short of what the tie blocks look like (53-64% against
+16%, with 43% zero bytes). The chunk bodies are denser and less float-shaped than
+tie geometry.
+
+**There is an index-like region near the tail.** In the largest type, **12 of 163**
+`u16` slots have a maximum below `0x1000` -- too small for float or half-float
+data, so those slots look like indices or small counts. They cluster at slots
+111-121 and 130-131.
+
+### A sample-size correction
+
+Dumping six records of one chunk showed slots 112-119 **zero on every record** and
+a long run of other constant slots, which read as "the record is mostly a
+per-chunk template". Measured properly across the 1,171 chunks with at least 8
+records:
+
+    u16 slots constant across every record in their chunk : 15,422 of 164,390 (9.4%)
+    chunks whose records are ENTIRELY constant             : 0 of 1,171
+
+So 9.4%, and no chunk is a template. Six records looked like a majority because
+that chunk's tail happens to carry shared constants -- the per-type figures range
+from 9.4% overall to 55.6% on one type. A pooled figure over all types would have
+hidden that spread again, so it is reported per type as well.