Exclude f32 and u16 readings of the shrub body record

Range measured: level 0 shrub bodies, 164 records of 8 bytes, following the
previous commit.

The six varying bytes are not an f32 pair:

  f32 @0  158/164 finite, range up to ~1e35. Not positions or normals. The 6
          non-finite values (3.7%) are far above the 0.05% random bytes would
          give, so the field is structured but is not an f32.
  f32 @4  164/164 finite, range 0 to 9.18e-5. Looks promising until you notice
          bytes 6 and 7 are always zero, which pins it to a coarse grid and
          explains the tiny range. Not independent evidence.
  u16 @0  85 distinct, range 0..65534
  u16 @2  90 distinct, range 0..65534
  u16 @4  80 distinct, range 0..65512

The u16 fields are not small counts or indices; they span essentially the whole
range.

Excluded: two packed u32, an f32 pair, and narrow u16 fields. The six bytes
remain uninterpreted.

Worth noting the f32 @4 case as a trap: a plausible-looking finite non-negative
float range that was entirely an artifact of the two constant zero bytes
pinning it. Checking the constant bytes before believing a float reading is now
the order to work in.

docs/formats/core-data-regions.md

@@ -1023,9 +1023,20 @@ 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.
+**What it does not.** Resolved by a follow-up measurement: the six bytes are
+not an `f32` pair either, and not narrow `u16`s.
+
+- `f32 @0`: 158 of 164 finite, but the range runs to about 1e35. Not positions
+  or normals. The 6 non-finite values (3.7%) are far above the 0.05% that
+  random bytes would produce, so the field is *structured* but is not an `f32`.
+- `f32 @4`: all 164 finite, range 0 to 9.18e-5. This looks promising until you
+  notice bytes 6 and 7 are always zero, which pins this value to a coarse grid
+  and explains the tiny range. It is not independent evidence.
+- `u16 @0`, `@2`, `@4`: distinct counts 85, 90 and 80, each spanning essentially
+  the whole 0..65534 range. These are not small counts or indices.
+
+So excluded are: two packed `u32`, an `f32` pair, and narrow `u16` fields. The
+six bytes remain uninterpreted.
 
 **Process note.** The first attempt at this used `ClassEntry` and a
 hand-computed `o_class` offset instead of `ShrubClassEntry`, and every