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.

docs/formats/core-data-regions.md

@@ -1429,15 +1429,28 @@ fits and `None` otherwise, so the 247 unexplained chunks are distinguishable
 from the 1,262 explained ones and nothing skips a leading byte on the strength of
 a rule that does not apply.
 
-### Every chunk has a uniform record length
+### RETRACTED: "every chunk has a uniform record length"
 
-**1,509 of 1,509 chunks.** Length varies between chunks of the same type -- one
-type runs 76 to 104 bytes -- but never within one chunk.
+**Claimed: 1,509 of 1,509 chunks. True: 257 of 1,509.**
 
-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. Within any one chunk the
-length is fixed.
+Length varies between chunks of the same type -- one type runs 76 to 104 bytes --
+and on 1,252 chunks it varies *within* one as well.
+
+**Both halves of that old entry were wrong, and both were mine.**
+
+"Never within one chunk" was `resolve` slicing every record at the chunk's first
+offset delta. Every record then came out the same length by construction, so the
+predicate was confirming the parser back to itself.
+
+And this section's *withdrawal* of "variable-length type" was wrong too. It read
+the pooled observation as a partitioning artifact -- `minlen`/`maxlen` taken across
+all of a type's records at once. Rule 3a is right about pooling in general, and it
+was applied to a real signal here: the type genuinely has variable-length records,
+and the per-chunk check that would have caught it was itself reporting the
+parser's own slicing.
+
+Two errors stacked. The pooling rule fired correctly and was overruled by a
+measurement that had no independent content.
 
 ## The first TWO bytes encode the record's own index