Measure sky sub-objects across levels; the stride table was over-fitted

Range measured: every level's sky region, from the count field at +0x0c
through the sub-object offsets at +0x20, each sub-object over its first
16384 bytes.

Method: peak-stride autocorrelation per sub-object with a matched control --
the same bytes shuffled, seeded per level and index.

Field note: the sub-object count is a u32 at +0x0c, not +0x0a. Reading +0x0a
gives 327,680 on level 0, which is not a count. A brief probe used the wrong
offset and read as though it were a count of 5; it got the right offsets by
accident because the offset table starts at +0x20 either way.

Level 0 has five sub-objects at 365760, 388880, 396432, 406784 and 414032,
of lengths 23120, 7552, 10352, 7248 and 1536, each with structure well clear
of its control.

But the strides do not repeat across levels:

  obj 0:  4 (x6),  8 (x13), 32, 288
  obj 1: 16 (x3), 32 (x6),  288
  obj 2:  8,     16 (x5), 256, 288
  obj 3:  8,     16 (x6), 216
  obj 4:  8,     16 (x3), 512 (x4)

So the per-index stride table read off level 0 alone was over-fitted to one
level, and is withdrawn. What is consistent is weaker and more honest: every
sub-object sits above its matched control, and most peak at 4, 8, 16 or 32,
suggesting 16- or 32-bit records whose stride varies with content.

Level 2's header is still genuinely different: its count field reads 196,617
and is unusable while every other level yields a plausible count.

docs/formats/core-data-regions.md

@@ -319,3 +319,39 @@ The contrast with sky is the point: the same statistic on the same kind of
 question gave a real answer in one region and an inflated one in the other,
 and the only thing that told them apart was whether the control matched the
 byte distribution.
+
+## Sky sub-objects: structure is consistent, stride is not
+
+**Range measured:** every level's sky region, from the count field at `+0x0c`
+through the sub-object offsets at `+0x20`. Each sub-object measured over its
+first 16,384 bytes.
+
+**Method:** as above, peak-stride autocorrelation per sub-object with a
+matched control (the same bytes shuffled, seeded per level and index).
+
+**Field note:** the sub-object count is a `u32` at **`+0x0c`**, not `+0x0a`.
+Reading `+0x0a` gives 327,680 on level 0, which is not a count.
+
+**Result, level 0:** five sub-objects at offsets 365760, 388880, 396432,
+406784 and 414032, of lengths 23120, 7552, 10352, 7248 and 1536. Each has
+internal structure well clear of its matched control.
+
+**But the strides do not repeat across levels.** Recomputing per level:
+
+| sub-object | peak strides seen across levels |
+|---|---|
+| 0 | 4 (x6), 8 (x13), 32, 288 |
+| 1 | 16 (x3), 32 (x6), 288 |
+| 2 | 8, 16 (x5), 256, 288 |
+| 3 | 8, 16 (x6), 216 |
+| 4 | 8, 16 (x3), 512 (x4) |
+
+So the earlier per-index stride table, read off level 0 alone, was
+over-fitted to one level. What is consistent is weaker and more honest: every
+sub-object sits above its matched control, and most peak at a small stride of
+4, 8, 16 or 32, which suggests 16- or 32-bit records whose stride varies with
+content rather than being fixed.
+
+**Level 2's header remains genuinely different**: its count field at `+0x0c`
+reads 196,617 and is unusable, while every other level yields a plausible
+count. Whatever makes it different is still unexplained.