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.

docs/formats/core-data-regions.md

@@ -831,7 +831,7 @@ take the stride as the first delta, load one record per offset at
 chunk's records.
 
 **Result: 1,096 chunks and roughly 13,000 records resolve on all 27 levels.**
-Every level's chunks show 17-21% of byte positions constant across their own
+Every level's chunks show 16.7-20.0% of byte positions constant across their own
 records — a consistent field layout rather than noise.
 
 Level 0 in detail: 27 chunks resolve, 466 records, 20.8% constant. The
@@ -2452,3 +2452,37 @@ since the two views are of the same bytes.
 The uniform model stays in place, the ambiguity is recorded here and in
 [`resolve`]'s docs, and the existing 1,509-of-1,509 assertion stands as a
 statement about what the parser does, not about what the disc contains.
+
+## Audit: which claims were contaminated by the over-read?
+
+The record-boundary fix changed the length of records in 1,252 of 1,509 chunks,
+so every committed claim computed over *record bytes* had to be re-checked. All of
+them:
+
+| claim | reads | verdict |
+| --- | --- | --- |
+| 1,509 chunks, 34,491 records | offsets, not records | 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 distinct strides, all multiples of 4 | offsets | unaffected |
+| moby class IDs in one slot per chunk type | record bytes | **retracted** |
+| 17-21% of byte positions constant | record bytes | **survives** |
+
+Only the claims that scanned *across* a record's body were at risk, and of those
+one was retracted (the class-ID slot) and one survived (the constant-byte
+statistic). The rest read the first three bytes of a record, which the over-read
+never touched -- an over-read appends to the end, so a claim about a record's
+*start* was never in danger. That asymmetry is why the damage was contained, and
+it is the reason to prefer claims anchored at record starts.
+
+The surviving one is worth stating precisely because it was the obvious candidate
+for contamination. Re-measured with each record bounded by its successor, and
+comparing only the span every record in the chunk has:
+
+    per level, % of byte positions constant within a chunk
+      lowest  level 8   16.7%
+      highest           20.0%
+
+Still inside the documented band, now asserted rather than only described, in
+`chunk_records_share_a_layout_measured_by_constant_byte_positions`.