recovery hardening for the quintillion-seq incident: a torn tail left bytes that decoded to a structurally-valid header (good kind, plausible len, body present) but whose seq field was actually CBOR payload (0x6363a382...). the scan trusted that seq and every restart since resumed garbage+1, relocating the whole sequencer into a junk space. the writer assigns seqs densely (seq = cur_seq; cur_seq += 1) and a file begins at exactly its seq_start, so scanForLastSeq now also requires the first record's seq == seq_start and each subsequent == prev + 1. a record that breaks the chain is the torn-tail boundary even if kind+len look plausible — recovery stops there and resumes in the real space (or falls back to seq_start if the very first record is already garbage). regression test plants a structurally-valid record carrying the garbage CBOR seq and asserts the scan rejects it; a second case asserts a garbage-from- record-one file recovers nothing (→ resumeLog falls back to seq_start). does not repair the existing bogus on-disk space — that's a separate coordinated operator action once a restore target is chosen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>