Note in the roadmap that shrub header fields are checked, not just reported

docs/roadmap.md

@@ -206,9 +206,11 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [ ] `tie` — instanced environment geometry, fat vertices
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at
       32 still gives 231 sane-looking entries of 358, which is the hazard).
-      Geometry header self-identifies at two points: `+0x24` equals the entry's
-      own `o_class` on all 358 spans, and `+0x2c` is an in-span data offset on
-      all 358. Shrub does **not** use moby's part-table format. Rest undecoded.
+      Geometry header parsed and both fields **checked**, not merely reported:
+      `+0x24` equals the entry's own `o_class`, and `+0x2c` is an in-span data
+      offset, on all 358 spans. Shrub does **not** use moby's part-table format.
+      The body past `+0x2c` is not decoded — it tiles at no stride consistent
+      with the count at `+0x28`.
 - [x] `moby` — per-class model geometry. A class span opens with a `u32`
       pointing at a part table of 16-byte records; parts tile exactly, with
       `vertex_offset + 16 * vertex_count == next_part` holding for **43,467 of