Retract the uniformity claim everywhere it still stood, including the API docs

The record-length retraction had been applied to the tests and to the section
that discovered the problem, but the same claim was still standing in four other
places -- including the rustdoc for has_uniform_record_length(), which is what a
caller would actually read:

  crates/gc-formats/src/chunks.rs:206   "Measured: true for 1,509 of 1,509 chunks"
  docs/roadmap.md:448                    "uniform record length (1,509 of 1,509)"
  docs/formats/core-data-regions.md      a whole section titled
                                         "Every chunk has a uniform record length"

All three now say 257 of 1,509, and the method's rustdoc explains WHY the old
number was an artefact -- that resolve sliced at the first offset delta, so every
record came out the same length by construction and the predicate was confirming
the parser back to itself.

That section also contained a withdrawal, and the withdrawal was wrong:

  "This withdraws the previous commit's variable-length type. That came from
   taking minlen/maxlen over all of a type's records at once, pooling across
   chunks; rule 3a's pooled claim, third time this session."

The pooling rule fired correctly and was overruled by a measurement with no
independent content. The per-chunk check that should have caught the pooled
signal was itself reporting the parser's own slicing, so it agreed with the wrong
answer for the same reason the original claim did. Two errors stacked: a real
signal dismissed by a rule that had been right twice already, and a predicate
that could not have told the difference.

This is the third time this session that a test was asserting the parser's
behaviour rather than the disc's, and the third time it was the only thing
standing between a claim and a retraction. has_uniform_record_length is the
clearest instance: a predicate named after a property of the data, returning a
confident answer about the code.

245 tests, clippy clean.

crates/gc-formats/src/chunks.rs

@@ -203,10 +203,21 @@ impl<'a> ResolvedChunk<'a> {
 
     /// True when every record in this chunk has the same length.
     ///
-    /// **Measured: true for 1,509 of 1,509 chunks** across all 27 levels. Record
+    /// **Measured: true for 257 of 1,509 chunks** across all 27 levels. Record
     /// length varies *between* chunks of the same type -- one type runs 76 to 104
-    /// bytes -- but never within one. An earlier claim that some type had
-    /// variable-length records was pooling across chunks; it is withdrawn.
+    /// bytes -- and, on 1,252 chunks, *within* one as well.
+    ///
+    /// This method used to report 1,509 of 1,509, and that was an artefact of
+    /// `resolve`: it sliced every record at the chunk's first offset delta, so
+    /// every record came out the same length by construction, and this predicate
+    /// was confirming the parser back to itself. `resolve` now bounds each record
+    /// by its successor's offset, which is the only coherent reading -- a record
+    /// of the nominal stride would overlap the next one whenever the delta is
+    /// smaller, and an explicit offset table cannot express an overlap.
+    ///
+    /// So the earlier withdrawal, "an earlier claim that some type had
+    /// variable-length records was pooling across chunks", was also wrong. The
+    /// records are variable-length and were never anything else.
     pub fn has_uniform_record_length(&self) -> bool {
         let mut it = self.records.iter().filter(|r| !r.is_empty());
         let Some(first) = it.next().map(|r| r.len()) else {