The previous commit inferred a 16-byte record from "922 of 922 consecutive block
sizes are a multiple of 16". That inference does not hold, and the claim is
withdrawn rather than softened.
What survives:
- Every one of those 922 blocks opens with a u32 that is positive and a multiple
of 4, on 922 of 922, ranging 48 to 1744 with 17 distinct values across level
0's LOD0 blocks. The block opens with a count, not a size and not a pointer.
- Reading that u32 as a byte size and chaining to the next block lands exactly on
the next block start on 0 of 1383 blocks. Not a size chain.
- Assuming [header][count][count uniform records] and solving for the record size
gives no answer: no record size tiles the block for any header size up to 512
bytes. Not 16, not 12, not 8.
- Reading the block as uniform 16-byte units gives fields spanning their entire
legal range -- u32@0 from -2139029504 to 2139029587, u16@8 and u16@10 both
0..65535, and 8969 distinct values in i16@0 on level 0. Uniform units would not
produce that.
So the 16 is a property of the block size, not of a record. The earlier commit
also claimed a record size "on the classes where it can be measured"; those
classes are still correctly identified, but what they measure is the block size.
The strict-increase disproof from two commits ago stands untouched and is what
should have prevented this: the word at +0 was already known not to behave, so
treating 16-byte units as records contradicted a measurement sitting in the same
file. Divisibility is arithmetic; it is not evidence of a record boundary.
Roadmap updated to say block sizes are established and the record layout is not,
with the three measurements that rule the 16-byte reading out.
ReaperOfVeriod
881fd48e9a