Correct the post-shrub 368 stride: real, but in one 15 KB window

The claim that the post-shrub region has a 368-byte period throughout is
wrong. Re-measured over the whole region the curve is flat and near noise:

  stride   8  +0.027
  stride  12  +0.023
  stride 148  +0.009
  stride 340  +0.018
  stride 368  +0.018
  stride 632  +0.020

Nothing peaks at 368, and the 0.1110 recorded earlier does not reproduce under
any sampling convention tried.

Where the structure is: scanning 8 KB windows at 1 KB steps for a 368-excess
above 0.15 finds one substantial region, region+41984..+57344, 15360 bytes,
plus a 4 KB patch at region+650240.

Within that window 368 is unambiguous -- +0.315 against +0.284 at 736, with
364, 372 and 732 all at noise. 41 whole records, mean 16 distinct values per
position, and nine positions exactly constant and zero: 329-336 and 340.
Twenty-five positions have 3 or fewer distinct values, clustered in 325-349,
which is a tail rather than scattered padding.

Corrected statement: a 15360-byte window of the post-shrub region is a table
of 41 records at stride 368, each with a roughly 43-byte tail whose fields are
mostly zero. The surrounding 675 KB is not that table.

What went wrong before: the original measurement was taken over a window where
368 held, then reported as a property of the region. That window holds 41 of
1841 records, and averaging it over the region flattens the peak to the noise
floor. The re-verification checked the stride but not whether it applied
uniformly, so it confirmed the number without testing the claim attached to it.

docs/formats/core-data-regions.md

@@ -670,3 +670,58 @@ 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.
+
+## Correction: the 368 stride is real, but confined to one ~15 KB window
+
+The claim earlier in this file that the post-shrub region has a 368-byte
+period *throughout* is wrong. Re-measured over the whole region, the
+autocorrelation curve is flat and near noise:
+
+| stride | excess over matched shuffled control |
+|---|---|
+| 8 | +0.027 |
+| 12 | +0.023 |
+| 148 | +0.009 |
+| 340 | +0.018 |
+| **368** | **+0.018** |
+| 632 | +0.020 |
+
+Nothing peaks at 368. The figure of 0.1110 recorded earlier does not
+reproduce under any sampling convention tried (step 1, 2 or 4 through the
+window; all give ~0.018).
+
+**Where the structure actually is.** Scanning 8 KB windows at 1 KB steps for
+a 368-excess above 0.15 finds exactly one substantial region:
+
+    region+41984 .. region+57344   = 15,360 bytes   (abs 16089024..16104384)
+
+plus a 4 KB patch at region+650240. Everything between and around is flat.
+
+**Within that window the 368 stride is unambiguous:**
+
+| stride | excess |
+|---|---|
+| **368** | **+0.315** |
+| 736 | +0.284 |
+| 364 | +0.024 |
+| 372 | +0.021 |
+| 732 | +0.027 |
+
+The peak is sharp, 736 confirms it as a multiple, and the neighbours are at
+noise.
+
+**Record shape.** 41 whole 368-byte records. Mean distinct values per
+position is 16 of 41, and **nine positions are exactly constant and zero**:
+329 through 336, and 340. Twenty-five positions have 3 or fewer distinct
+values, clustered in 325-349 -- a tail region rather than scattered padding.
+
+So the corrected statement is: a 15,360-byte window of the post-shrub region
+is a table of 41 records at stride 368, each with a roughly 43-byte tail
+whose fields are mostly zero. The surrounding 675 KB is not that table.
+
+**What went wrong before.** The original measurement was taken over a window
+where 368 held and then reported as a property of the region. The 15 KB
+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.