Characterise all 77 chunk types: record byte 0 is a bucket index, not data

Characterised every chunk type -- 77 of them, 1,509 chunks, 34,491 records, all 27
levels.

Byte 0 of every record is a small aligned index, not record content. It takes 16
discrete values per chunk type (0x00, 0x10, ... 0xf0) with near-uniform counts
WITHIN each type. Uniform weighting is the tell: a running byte offset would
weight the buckets unevenly, because records differ in size.

  type_id      recs  len  byte0
  0x007d7ec438 2430  328  0x00:162 0x10:162 0x20:162 ... 0xf0:135
  0x00429ec43d 2079  368  0x00:162 0x10:135 0x20:135 ... 0xf0:108
  0x00d76cc453  810  108  0x00:27  0x08:27  0x10:27  ... 0xe8:27   <- steps by 8

The alignment step is per type, not global. The leading byte is a multiple of 8 on
34,432 of 34,491 records but a multiple of 16 on only 33,349 -- the 1,142-record
difference falls in seven types, four of which step by 8. 59 records in three types
break even the 8-byte rule, and that is where the variable-length type lives:
0x00f2ef4275, records 76 to 104 bytes, no single stride to align to.

What the bucket indexes is NOT named. It is reported as CHUNK_RECORD_ALIGNMENT and
record_is_aligned rather than as a parsed field, because naming it would be a guess
while the invariant is solid. The test pins the exact exception set -- 59 records
across 3 types -- so a change there fails loudly.

A measurement I initially got wrong: the first version of the constant claimed a
16-byte multiple on 34,432 records. 34,432 is the multiple-of-8 count; the
multiple-of-16 count is 33,349. Right number, wrong label, and the test caught it.
That is the second time this session a correct number carried a wrong label, after
the tie four-value retraction. Both times the assertion did, which is the argument
for putting these numbers in tests rather than only in prose.

Still open: what the bucket indexes, and the remaining record fields.

docs/formats/core-data-regions.md

@@ -1272,3 +1272,47 @@ not automatically better than the claim it retracts; it needs its own bounds.
 `+0x0c` clusters around 1,087 to 1,091, close enough to a block length to be
 worth stating, but it is **not** the length: the difference against the true
 payload length scatters from -12 to -172.
+
+## chunk records: the leading byte is a bucket index, not data
+
+Characterised across **all 77 chunk types**, 1,509 chunks and 34,491 records on
+all 27 levels.
+
+**Byte 0 of every record is a small aligned index.** It takes 16 discrete values
+per chunk type -- 0x00, 0x10, ... 0xf0 -- with near-uniform counts *within* each
+type. Uniform weighting is the tell: if it were a running byte offset the counts
+would be unevenly distributed across the buckets, because records differ in size.
+
+```
+type_id      recs  len  byte0
+0x007d7ec438 2430  328  0x00:162 0x10:162 0x20:162 ... 0xf0:135
+0x00d3d8c4a9 2430  308  0x00:162 0x10:162 0x20:162 ... 0xf0:135
+0x00429ec43d 2079  368  0x00:162 0x10:135 0x20:135 ... 0xf0:108
+0x00d76cc453  810  108  0x00:27  0x08:27  0x10:27  ... 0xe8:27   <- steps by 8
+```
+
+**The alignment step is per type, not global.** The leading byte is a multiple
+of 8 on **34,432 of 34,491** records, but a multiple of 16 on only **33,349** --
+the 1,142-record difference falls in seven types, four of which step by 8.
+
+59 records in three types break even the 8-byte rule. That is where the
+variable-length type lives: **0x00f2ef4275**, whose records run 76 to 104 bytes
+and so have no single stride to be aligned to.
+
+**Not named.** What the bucket indexes is not established. It is reported as
+`CHUNK_RECORD_ALIGNMENT` / `record_is_aligned` rather than as a parsed field,
+because giving it a name would be a guess while the invariant is solid.
+
+### A measurement I initially got wrong
+
+The first version of the constant claimed a 16-byte multiple on 34,432 records.
+34,432 is the **multiple-of-8** count; the multiple-of-16 count is 33,349. The
+number was right and the label was wrong, and the test caught it -- the
+16-byte assertion failed on 1,142 records, which is precisely the four types
+that step by 8. Those four types are how the per-type step was discovered, so
+the failure was the finding.
+
+Worth stating plainly: this is the second time this session a correct number
+carried a wrong label, after the tie four-value retraction. Both times the test
+was the thing that caught it, which is the argument for asserting the number in
+a test at all rather than only in prose.