The defect itself was measured and committed in 572cd18, but the format-doc
section describing it was lost last session: the patch that should have added it
silently failed its assertion, and only the test and the roadmap entry landed.
Same shape as three other lost edits this session. The section is restored here.
Two candidate fixes are recorded alongside it, both measured and both dead
ends:
1. The first 0xf6 00 at or after the last known packet's end. The offsets
found are spread (1082, 1132, 1148, 1150, 1182, 1214 ...), not concentrated,
because the 115 records with a non-zero strip_count carry packets of unknown
length that sit after the last known end.
2. The block's data ends at a long zero run. The byte before the first 8+ zero
run is not dominated by 0xf6 (2, 4, 1, 64, 3, 32, 19 ...), and the runs are
mostly 8-31 bytes, so run length does not discriminate the block's end.
Both are recorded because they are the obvious things to try next. What would
unblock it: a survey of which offsets do bound blocks (the 461 that work may
share a property), or the level loader's own block-walking code, which needs the
overlay relocation from Phase 3.
ReaperOfVeriod
855aadf523