Show the chunk record's leading byte is a per-chunk phase counter; every chunk

has a uniform record length

Follows the alignment result and settles what the leading byte is.

Within one chunk the leading byte steps by a constant and wraps:

  offsets: 1420 1748 2072 2392 2716 3044 3372 3700 4028 4352 ...
  byte0:      0  16   32   48   64   80   96  112  128  144 ...

Sweeping every (step, phase) over all 27 levels:

  fully explained: 1,262 of 1,509 chunks
  by step: 8 -> 51 chunks, 16 -> 554, 32 -> 520, 64 -> 137
  unexplained:  247 chunks across 11 chunk types

So on 1,262 chunks the leading byte carries no per-record information: it is a
deterministic function of the record's index and the chunk's phase, which is a
position marker rather than data. That is why the earlier "16 discrete values,
uniform counts" pattern appeared at all.

ResolvedChunk::bucket_rule returns the (step, phase) when the whole chunk fits and
None otherwise, so the 247 unexplained chunks stay distinguishable and nothing
skips a leading byte on the strength of a rule that does not apply to it.

Every chunk has a uniform record length: 1,509 of 1,509. Length varies BETWEEN
chunks of a type -- one type runs 76 to 104 bytes -- but never within one. This
withdraws the previous commit's "variable-length type", which came from pooling
minlen/maxlen across all of a type's records at once. That is the pooled-claim
error rule 3a exists to prevent, and it is the third time this session a pooled
measurement produced a claim that partitioning reversed. The type is not
variable-length; the chunk is fixed-length and different chunks differ.

docs/formats/core-data-regions.md

@@ -1316,3 +1316,39 @@ 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.
+
+## The chunk record's leading byte is a per-chunk phase counter
+
+Follow-up to the alignment result, and it settles what the leading byte is.
+
+Within one chunk the leading byte steps by a constant and wraps:
+
+    offsets: 1420 1748 2072 2392 2716 3044 3372 3700 4028 4352 ...
+    byte0:      0  16   32   48   64   80   96  112  128  144 ...
+
+i.e. `byte0 == step * ((index + phase) mod (256 / step))`. Sweeping every
+`(step, phase)` over all 27 levels:
+
+    fully explained: 1,262 of 1,509 chunks
+    by step: 8 -> 51 chunks, 16 -> 554, 32 -> 520, 64 -> 137
+    unexplained:  247 chunks across 11 chunk types
+
+**So on 1,262 chunks the leading byte carries no per-record information.** It is
+a deterministic function of the record's index and the chunk's phase. That makes
+it a position marker, not data -- which is why the earlier "16 discrete values
+with uniform counts" pattern showed up.
+
+`ResolvedChunk::bucket_rule` returns the `(step, phase)` when the whole chunk
+fits and `None` otherwise, so the 247 unexplained chunks are distinguishable
+from the 1,262 explained ones and nothing skips a leading byte on the strength of
+a rule that does not apply.
+
+### Every chunk has a uniform record length
+
+**1,509 of 1,509 chunks.** Length varies between chunks of the same type -- one
+type runs 76 to 104 bytes -- but never within one chunk.
+
+This **withdraws the previous commit's "variable-length type"**. That came from
+taking `minlen`/`maxlen` over all of a type's records at once, pooling across
+chunks; rule 3a's pooled claim, third time this session. Within any one chunk the
+length is fixed.