Crash-recovery calibration

• FS1: after only append, crash restores the old state. After the complete log is persisted, recovery installs its value even if the data checkpoint is old. Acknowledgement is observer knowledge, not an additional persistence operation.
• FS2: two-record prefix lengths 0–3 yield initial zero, 4–7 yield 7, and 8 yields 3 for values 7 then 3. Invalid complete records raise; incomplete suffix bytes are never applied. XOR is neither strong integrity protection nor authentication.
• FS3: reference output alone earns no implementation credit. Ask for a changed value and independently predicted crash cut. The full log remains available; this exercise supplies no log-reclamation proof.
• FS4: success after volatile append can be lost. Repeated assignment replay converges; adding after-images to the checkpoint does not. Require an observed counterexample and corrected trace.
• FS5: durable commit without response can survive recovery. The client cannot infer rollback merely from a timeout. A process kill leaves other buffering layers alive; rename visibility and durability are different obligations. Platform API errors cannot be ignored.
• FS6: a new cut must be defended without copying a previous matrix. A strong answer names the new invariant for a proposed extension, such as durable checkpoint before log deletion, rather than claiming the small model already handles it.

Repair failed gates with new values/cuts. Keep assistance disclosures and the original failed reasoning visible.