Show the first two chunk-record bytes encode the record's own index

Continuing from the phase counter. Within a chunk:

  i    :  0  1  2  3  4  5  6  7  8  9 10 11 ... 15 16 17 ...
  byte0:  0 16 32 48 64 80 96 112 128 144 160 176 ... 240  0 16 32
  byte1:  0  0  0  0  0  0  0  0  0  0  0  0 ...   0  1  1  1

byte0 is step*(j mod g) and byte1 is (j / g), where g = 256/step and
j = index + phase. The pair is the record's index in mixed radix: byte0 carries
the low digits scaled by step, byte1 the quotient.

Measured over all 27 levels: 1,235 of 1,509 chunks fit this on both bytes. Byte 0
alone fits 1,262, so the 27-chunk difference are chunks whose first byte follows
the rule and whose second does not. On 1,235 chunks a record knows its own
position and the two leading bytes hold no per-record information.

ResolvedChunk::index_rule returns the (step, phase) only when the whole chunk fits
on BOTH bytes, so the 274 that do not stay distinguishable and nothing skips a
leading byte on a rule that does not apply to it.

A number that moved when the implementation changed: a first probe reported
1,181; the committed method reports 1,235. The method is right. The probe
accumulated ok0/ok1 flags across candidate phases with an early-exit that could
skip a phase which would have matched both bytes, and it also disagreed with
bucket_rule on the byte-0 count (1,208 against 1,262), which is what gave it away.

Recorded because both numbers came from the same run and only the discrepancy
exposed the probe as wrong. The lesson is narrow: when a one-off probe and a
committed helper disagree, check the probe first.

docs/formats/core-data-regions.md

@@ -1352,3 +1352,36 @@ 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.
+
+## The first TWO bytes encode the record's own index
+
+Continuing from the phase counter. Within a chunk:
+
+    i    :  0  1  2  3  4  5  6  7  8  9 10 11 ... 15 16 17 ...
+    byte0:  0 16 32 48 64 80 96 112 128 144 160 176 ... 240  0 16 32
+    byte1:  0  0  0  0  0  0  0  0  0  0  0  0 ...   0  1  1  1
+
+`byte0` is `step * (j mod g)` and **`byte1` is `(j / g)`**, where `g = 256/step`
+and `j = index + phase`. So the pair is the record's index in mixed radix:
+`byte0` carries the low digits scaled by `step`, `byte1` the quotient.
+
+**Measured over all 27 levels: 1,235 of 1,509 chunks** fit this on both bytes.
+Byte 0 alone fits 1,262, so the 27-chunk difference are chunks whose first byte
+follows the rule and whose second does not.
+
+**So on 1,235 chunks a record knows its own position**, and the two leading bytes
+hold no per-record information. `ResolvedChunk::index_rule` returns the
+`(step, phase)` only when the *whole* chunk fits on both bytes, so the 274 that
+do not stay distinguishable.
+
+### A number that moved when the implementation changed
+
+A first probe reported **1,181**; the committed method reports **1,235**. The
+method is right. The probe accumulated `ok0`/`ok1` flags across candidate phases
+with an early-exit that could skip a phase which would have matched both bytes,
+and it also disagreed with `bucket_rule` on the byte-0 count (1,208 against
+1,262), which is what gave it away.
+
+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.