Note that the SBlk period is not a record boundary

Range measured: level 0 SBlk, 24..19508, read at 4-byte alignment.

The most common u32 values are 0x0 (2261), 0x1 (369), 0x7f (168),
0x5a000000 (125), 0x1eff7f7f (125), 0x1dfcc (124), 0x19fc0 (93),
0x7c34240d (91), 0x7c3821c8 (91).

That does not look like a table of records with typed fields. A 40-byte layout
of index, length and offset would not produce 0x1eff7f7f and 0x7c34240d a
hundred times each, nor would those values survive a byte shift.

So either the 40-byte period is not a record boundary, or the region is an
encoded stream that happens to have a 40-byte statistical period. The 0x7f
values point at the latter: in a varint encoding 0x7f is the largest value
representable in seven bits, so it appears as a frequent saturated byte --
consistent with a coded stream, inconsistent with fixed-layout records.

Left open. The 40-byte period is solid -- 27 of 27 levels, sharply isolated,
multiples confirming -- and so is the alignment with four constant zero
positions. But those two are in tension in a way nothing else in this project
has been: a confirmed period that is not a record boundary. Someone attacking
this format should not assume the record framing that the autocorrelation
suggests.

docs/formats/core-data-regions.md

@@ -640,3 +640,33 @@ accounting for before reading any field at a fixed offset.
 **Not decoded.** The layout is established and the constant positions are
 known; the fields are not named, and which of the 40 bytes are an index, a
 length and an offset is still open.
+
+## SBlk: the field values do not read as record fields
+
+**Range measured:** level 0 `SBlk`, 24..19508.
+
+**Method:** read at 4-byte alignment and rank the most common `u32` values.
+
+**Result:** the common values are `0x0` (2261), `0x1` (369), `0x7f` (168),
+`0x5a000000` (125), `0x1eff7f7f` (125), `0x1dfcc` (124), `0x19fc0` (93),
+`0x7c34240d` (91), `0x7c3821c8` (91).
+
+**This does not look like a table of records with typed fields.** A 40-byte
+record layout whose fields are an index, a length and an offset would not
+produce `0x1eff7f7f` and `0x7c34240d` a hundred times each, nor would those
+values survive a byte shift.
+
+So either the 40-byte period is not a record boundary, or the region is an
+encoded stream -- something like varint or Huffman-coded data -- that happens
+to have a 40-byte statistical period.
+
+The `0x7f` values are suggestive: in a varint encoding a byte of `0x7f` is the
+last value representable in seven bits, so it appears as a frequent
+saturated byte. That is consistent with a coded stream and inconsistent with
+a fixed-layout record.
+
+**Left open.** The 40-byte period is solid (27/27 levels, sharply isolated, its
+multiples confirm it), and the alignment with four constant zero positions is
+solid. What sits in those bytes is not a record layout, and the two findings
+are in tension in a way this project has not otherwise seen: a confirmed
+period that is not a record boundary.