test: drive the fault-injection backend through the full save/WAL/recovery paths #390

Problem

src/storage/backend/fault_inject.rs (FaultInjectingBackend) exists, but only a small fault_injection_tests module in persistent_facts.rs uses it. No integration test covers these failures at every point in save(), WAL append, checkpoint and recovery:

• short writes
• torn pages
• fsync failure (EIO)
• ENOSPC

fsync failure matters most. After a failed fsync, the page cache may already have dropped the dirty pages. Retrying the fsync can then report success even though the data was never written (the PostgreSQL "fsyncgate" problem).

Ask

• Add a test matrix that injects each fault at each write or sync call during transact, checkpoint and save(). After each fault, reopen the database. The data must be either the last committed state or a clear error, and must never be wrong.
• Decide and write down what happens after an fsync failure. The safe choice is to poison the handle and make the caller reopen, not to retry.
• Add an ENOSPC test in which the disk fills halfway through a checkpoint.