Audit what the record-boundary fix contaminated: one retraction, one survivor

The fix changed record lengths in 1,252 of 1,509 chunks, so every committed claim
computed over record bytes needed re-checking rather than assuming. All of them:

  claim                                        reads            verdict
  1,509 chunks / 34,491 records                offsets          unaffected
  1,262 chunks with a leading-byte bucket rule record byte 0    unaffected
  1,235 chunks with an index rule              record bytes 1-2 unaffected
  34,432 of 34,491 records 8-byte aligned      record byte 0    unaffected
  55 strides, all multiples of 4               offsets          unaffected
  moby class IDs in one slot per chunk type    record bytes      RETRACTED
  17-21% byte positions constant               record bytes      SURVIVES

Only claims that scanned across a record's BODY were at risk. The rest read a
record's first three bytes, which an over-read never touched -- it appends to the
end. That asymmetry is why the damage was contained to one claim, and it is the
argument for preferring claims anchored at record starts.

The survivor was the obvious candidate for contamination, so it is worth being
precise about it. Re-measured with each record bounded by its successor, and
comparing only the span every record in the chunk has (they are no longer all the
same length):

    lowest   level 8   16.7%
    highest             20.0%

Still inside the documented band. Previously this lived only in a doc comment on
the layout test; it is now asserted, in
chunk_records_share_a_layout_measured_by_constant_byte_positions, over all 27
levels with a 10-30% band so a real change reports itself rather than sliding.

The module documentation is corrected to the measured range and now says outright
that records in one chunk are not all the same length, since that is the fact a
reader would otherwise have to rediscover.

244 tests, clippy clean.

crates/gc-formats/src/chunks.rs

@@ -16,9 +16,11 @@
 //! ```
 //!
 //! and each tagged offset is `0xF0000000 | low24`. Resolving a record at
-//! `chunk_start + low` yields records that share a field layout: 17-21% of
-//! byte positions are constant across a chunk's own records, on every level.
-//! That is what distinguishes this from a coincidental byte pattern.
+//! `chunk_start + low` yields records that share a field layout: 16.7% to 20.0%
+//! of byte positions are constant across a chunk's own records, on every level.
+//! That is what distinguishes this from a coincidental byte pattern. Records in
+//! one chunk are **not** all the same length -- each runs to its successor's
+//! offset -- so the statistic is computed over the span every record shares.
 //!
 //! The stride between records is a property of the chunk, not of the region.
 //! Level 0 alone contains chunks at 148, 340, 368, 288, 320, 236, 272, 384,