Identify the post-shrub region as a chunk container

Range measured: level 0 post-shrub, 16047040..16737344, 690304 bytes.

Method: scan for a 16-byte header ending 0xff, then 10 zero bytes, then a run
of u32 whose top nibble is 0xF.

Result: 28 chunk headers on level 0, present on all 27 levels. Each chunk is

  +0x00  16 bytes, last byte 0xff   (opaque, differs per chunk)
  +0x10  10 zero bytes
  +0x1a  N tagged offsets, top nibble 0xF

Within a chunk the offsets step by a chunk-specific stride. On level 0:
148, 340, 368, 288, 320, 236, 272, 384, 116, 160, 250, 580, 576. Near-constant
within a chunk, different between chunks.

This resolves two earlier results, both of which were half-right.

The 368-byte period is one chunk's stride, not a region property. That is why
the region-wide autocorrelation is flat: ~15 strides averaging to noise. The
15360-byte window where 368 scored +0.315 is the third chunk at region+30066,
whose stride is 368.

The "ten-entry table" earlier disconfirmed is real. Chunks carry 5 to 30 tagged
offsets, 10 most common on level 0. It was disconfirmed because I tested for a
fixed 148 stride across a whole region; the table exists, but 148 is one
chunk's stride among many.

Both errors were the same one: reporting a local measurement as a regional
property. Twice now. The control methodology caught neither, because a matched
control bounds significance but says nothing about scope.

Not decoded: the 16-byte header, the 0xF tag, where chunk data lives, and what
any chunk means. Framing established, contents not.

docs/formats/core-data-regions.md

@@ -725,3 +725,42 @@ window holds 41/1841 of the region's records, and averaging that over the
 whole region flattens the peak to the noise floor. The re-verification pass
 checked the stride but not whether it applied uniformly, so it confirmed the
 number without testing the claim it was attached to.
+
+## The post-shrub region is a chunk container (explains the 368 stride)
+
+**Range measured:** level 0 post-shrub, 16047040..16737344 (690,304 bytes).
+
+**Method:** scan for the block shape `16-byte header ending 0xff` followed by
+10 zero bytes followed by a run of `u32` whose top nibble is `0xF`.
+
+**Result: 28 chunk headers on level 0**, present on all 27 levels. Each chunk
+is:
+
+    +0x00  16 bytes, last byte 0xff     (opaque; differs per chunk)
+    +0x10  10 zero bytes
+    +0x1a  N tagged offsets, top nibble 0xF
+
+and within a chunk the offsets step by a **chunk-specific stride** — 148,
+340, 368, 288, 320, 236, 272, 384, 116, 160, 250, 580, 576 all occur on
+level 0. The stride is near-constant within a chunk (e.g. 148,148,148,148...
+then 340,340,336,340...) but differs between chunks.
+
+**This resolves two earlier results.**
+
+The "368-byte period" is one chunk's stride, not a property of the region.
+That is why the region-wide autocorrelation is flat: the region holds chunks
+with ~15 different strides averaging out to noise. The 15,360-byte window where
+368 scored +0.315 is the third chunk, at region+30066, whose stride is 368.
+
+The "ten-entry table" I earlier disconfirmed is real — chunks carry 5 to 30
+tagged offsets, with 10 the most common on level 0. It was disconfirmed because
+I tested for a fixed stride of 148 across a whole region; the table exists,
+but 148 is one chunk's stride among many.
+
+**Two corrections this produces.** Both earlier claims were half-right: real
+structure, wrong scope. I reported a local measurement as a regional one in
+both cases, which is the same mistake twice.
+
+**Not decoded.** What the 16-byte header is, what the `0xF` nibble tags, where
+the chunk data lives, and what the chunk *means* are all open. The container
+framing is established; its contents are not.