Characterise shrub body records on level 0 as a per-level partition

Range measured: level 0, shrub class table, 7 entries at core index offset
10176. Six classes are bounded by a successor; the seventh runs to the end of
core_data and is excluded because its span contains the whole post-shrub
region.

Method: bound each span by the next class geometry offset, take the body from
data_offset to the span end, split into 8-byte records.

Result: 164 records across 6 bounded bodies, lengths 192 twice, 208 twice, 224,
240.

Per byte over those 164 records:

  byte 0: 74 distinct, 60 zero      byte 4: 72 distinct, 35 zero
  byte 1: 58 distinct, 65 zero      byte 5: 59 distinct, 38 zero
  byte 2: 76 distinct, 43 zero      byte 6:  1 distinct, 164 zero
  byte 3: 62 distinct, 48 zero      byte 7:  1 distinct, 164 zero

Bytes 6 and 7 are zero in every record; bytes 0 to 5 take 58 to 76 distinct
values with only 21 to 39% zero, so uniformly varied rather than sparse.

Read as u32 the fields are not plausible: u32[0] spans 0 to 4294871316 and no
field is monotone across the body. The six bytes are not two packed 32-bit
values.

This settles the six-varying-plus-two-constant shape on level 0 as a per-level
partition, rather than only in aggregate over the disc's 8938 records, which
is what rule 3a asks for. Two trailing zero bytes are padding or a flag pair.

Unresolved: whether the six bytes are six u8, an f32 plus two u16, or
something else. The u32 reading is excluded but no positive reading is
established.

Process note: the first attempt used ClassEntry and a hand-computed o_class
instead of ShrubClassEntry, and every ShrubHeader::region call failed. The
parser was fine; the caller was not.

docs/formats/core-data-regions.md

@@ -983,3 +983,51 @@ array is a per-type field, not a common one at a fixed offset.
 
 The moby reference itself is unaffected: 38.6x excess measured across all
 records stands, since it does not depend on which slots were counted.
+
+## Shrub body records on level 0: six varying bytes, two constant
+
+**Range measured:** level 0, shrub class table 7 entries at core index offset
+10176. Six classes are bounded by a successor; the seventh runs to the end of
+`core_data` and is excluded, because its span contains the whole post-shrub
+region and is not wholly records.
+
+**Method:** bound each span by the next class's geometry offset, take the body
+from `data_offset` to the span end, and split into 8-byte records.
+
+**Result: 164 records across 6 bounded bodies**, body lengths 192 (twice), 208
+(twice), 224, 240.
+
+Per-byte, over those 164 records:
+
+| byte | distinct | zero |
+|---|---|---|
+| 0 | 74 | 60 |
+| 1 | 58 | 65 |
+| 2 | 76 | 43 |
+| 3 | 62 | 48 |
+| 4 | 72 | 35 |
+| 5 | 59 | 38 |
+| **6** | **1** | **164** |
+| **7** | **1** | **164** |
+
+Bytes 6 and 7 are zero in every record. Bytes 0 to 5 take 58 to 76 distinct
+values of a possible 164, with only 21-39% zero -- that is, uniformly varied
+rather than sparse.
+
+Read as `u32` the fields are not plausible: `u32[0]` ranges 0 to 4,294,871,316
+and no field is monotone across the body. So the six bytes are not two packed
+32-bit values.
+
+**What this settles.** The six-varying-plus-two-constant shape holds on level 0
+as a per-level partition rather than only in aggregate across the disc's
+8,938 records, which is what rule 3a asks for. Two trailing zero bytes are
+padding or a flag pair, not data.
+
+**What it does not.** Whether the six bytes are six `u8` fields, or an `f32`
+plus two `u16`, or something else, is unresolved -- the `u32` reading is
+excluded but no positive reading is established.
+
+**Process note.** The first attempt at this used `ClassEntry` and a
+hand-computed `o_class` offset instead of `ShrubClassEntry`, and every
+`ShrubHeader::region` call failed. The parser was not wrong; the caller was.
+The working call shape was already in the disc test.