Show the chunk header does not encode the record stride

All 90 two-byte windows of header[0..14] were tested: none maps to a unique
stride across every group. There is no simple two-byte field to read the
record size from.

The stride must therefore come from the offset table, by differencing the
first two tagged offsets, which is what the parser already does.

This validates that choice as more than convenience. Given three chunks sharing
one header with three different strides, a dispatch that assumed "header
implies size" would be wrong for the whole type-ID coverage on at least one
layout. Reading the stride from the offsets is the only interpretation
consistent with every measurement so far.

Negative result recorded deliberately: it rules out a whole family of
hypotheses (stride encoded in the header) rather than narrowing one.

docs/formats/core-data-regions.md

@@ -875,6 +875,19 @@ This does not change the earlier conclusion that 63 of 64 headers imply one
 stride -- that remains 63 of 64 -- but the mapping is not a bijection and
 should not be used as one.
 
+**The header does not encode the stride.** All 90 two-byte windows of
+`header[0..14]` were tested: none maps to a unique stride across every group.
+So there is no simple two-byte field to read the record size from, and the
+stride must come from the offset table, as the parser already does, by
+differencing the first two tagged offsets.
+
+That is the right implementation anyway, and this makes it more than a
+convenience: given three chunks sharing one header with three different
+strides, any dispatch that assumed "header implies size" would be wrong for
+1,123 chunks' worth of type coverage on at least one layout. Reading the
+stride from the offsets is the only interpretation consistent with all the
+measurements.
+
 **The ASCII reading is confirmed as a type tag.** Grouping by header bytes 9
 and 13: