fix(recovery): SSTable auto-repair, chaos tests, WAL decoupling, group commit config

[ElioNeto]

Summary

Four complex issues resolved:

CRASH-SST-001 (#357) — SSTable Auto-Repair

• discover_sstables_from_disk validates each SSTable on startup
• Corrupted/truncated SSTables are moved to quarantine/ subdirectory
• Data recovered via WAL replay (runs before SSTable discovery)
• Added quarantined_count and recovered_count to engine stats

TEST-003 (#373) — Chaos Testing

• 6 chaos tests for I/O fault tolerance and corruption handling
• Tests: deleted SSTable, compact with missing SSTable, restart with missing SSTable, corrupted data blocks, corrupted bloom filter, missing WAL
• All tests verify engine survives without panic

WRITE-SERIAL-001 (#362) — Decoupled WAL I/O

• Writes now use two-phase approach: brief lock to clone Arc handle, then WAL I/O performed OUTSIDE the core lock
• Re-acquire lock briefly for memtable insert
• Concurrent writers can perform WAL I/O in parallel
• Crash-safe: WAL-before-memtable order preserved

WRITE-WAL-001 (#363) — WAL sync_interval config

• Added wal_sync_interval to EngineOptions and WalConfig
• Wired set_sync_interval() through engine initialization
• Default remains 4 (existing behavior)

MEM-MEMTABLE-002 (#367) — Analysis

• crossbeam-skiplist migration attempted but reverted due to fundamental lifetime incompatibility with the StorageIterator trait
• The Entry type uses epoch-based reclamation with different lifetime semantics
• Main contention issues already resolved by RwLock (BACKPRESSURE-001: CompactionBackpressure calcula delays mas não reduz rate limit da API #360) and WAL decoupling (WRITE-WAL-001: WAL sem group commit — fsync a cada 4 writes limita throughput #362)

Closes #357
Closes #373
Closes #362
Closes #363