General guard for the over-read class, and the audit showing it was unique

Searched for the pattern that caused the over-read -- a record length derived from
the first difference between two offsets:

    grep -rn "\[1\] - \[0\]" crates/gc-formats/src/*.rs
      crates/gc-formats/src/chunks.rs:357   (offsets[1] - offsets[0])

One hit, in the one parser that walks an explicit offset table.

The others slice contiguous regions with chunks_exact -- shrub's 8-byte palette
records, tie's 16-byte packet headers, tfrag's 4-byte tables. There a length
cannot run past the next element, because chunks_exact derives each boundary from
the region's own length rather than from a sample of the spacing. Shrub's mesh
packets carry an explicit offset AND size, so they state their length instead of
inferring it.

The damage was bounded by a structural property worth stating: only a format with
an offset table AND a derived stride can over-read, and exactly one format had
both. That is a more useful fact than the retraction was on its own -- it says
where else to look if another one turns up.

The guard is positive rather than a comment.
chunk_records_neither_overlap_nor_leave_gaps asserts across all 27 levels that
every record but the last is exactly its own offset delta long, that there are
1,509 chunks, and that 1,252 have ragged deltas. A regression to a single sampled
stride fails immediately and names the chunk and the record.

245 tests, clippy clean.

docs/formats/core-data-regions.md

@@ -2486,3 +2486,30 @@ comparing only the span every record in the chunk has:
 
 Still inside the documented band, now asserted rather than only described, in
 `chunk_records_share_a_layout_measured_by_constant_byte_positions`.
+
+## The over-read bug was unique to one format, and why
+
+Searched for the pattern that caused it -- a record length derived from the
+*first* difference between two offsets:
+
+    grep -rn "\[1\] - \[0\]" crates/gc-formats/src/*.rs
+      crates/gc-formats/src/chunks.rs:357   (offsets[1] - offsets[0])
+
+One hit, in the one parser that walks an explicit offset table.
+
+The other parsers slice contiguous regions with `chunks_exact` -- shrub's 8-byte
+palette records, tie's 16-byte packet headers, tfrag's 4-byte tables. There, a
+length cannot run past the next element, because `chunks_exact` derives each
+boundary from the region's own length rather than from a sample of the spacing.
+Shrub's mesh packets are named by an explicit offset *and size* table, so they
+carry their length rather than inferring it.
+
+So the damage was bounded by a structural property: **only a format with an
+offset table and a derived stride can over-read**, and exactly one format had
+both.
+
+The general guard is now positive rather than a comment.
+`chunk_records_neither_overlap_nor_leave_gaps` asserts, across all 27 levels,
+that every record except the last is exactly its own offset delta long, and that
+1,509 chunks contain 1,252 with ragged deltas. A regression to a single sampled
+stride fails immediately and says which chunk and which record.