fix(rocksdb): flush batch data into storage to make sure stage is completed

[AshinGau]

Problem

provider_rw.commit() calls rocksdb::DB::write() which appends to WAL but does not call fdatasync(). Data sits in OS page cache after write() returns. Background sync fires only every 4MB of WAL (wal_bytes_per_sync=4MB). Three separate DB instances (state_db, account_db, storage_db) have independent WAL counters:

• state_db gets ~50KB writes per block → syncs every ~80 blocks → data largely survives
• account_db / storage_db get ~0-2KB per empty block → may go 2000+ blocks without sync → massive data loss on power failure

Result: after crash, state_db checkpoints report consistency but trie DBs lost committed data. Consensus re-execution reads stale trie nodes → state root mismatch → panic.

Fix

1. tx.rs — every write() → write_opt(sync=true)

All 7 db.write() calls in commit_view() now use WriteOptions::set_sync(true). Every provider_rw.commit() is fsync-durable before returning.

2. mod.rs — disable pipelined write, remove wal_bytes_per_sync

With per-commit sync, background WAL sync and pipelining are redundant.

3. recovery.rs — always check all stage checkpoints

Removed early-return when recover_block == best_block. Each recover_* function has internal if ck < target guard → no-op when consistent, repair when not.

Fault tolerance after fix

persistence.rs          recovery.rs (always runs)
  [A] Execution (sync)    → recover_hashing  (if ck < target)
  [B] AccountHashing(sync)→ recover_merkle   (if ck < target)
  [C] HistoryIndex (sync) → recover_history  (if ck < target)
  [D] MerkleExecute(sync)

Each commit atomic on disk. Any crash point → recovery scans all stages → rebuilds only what is behind. No blind spots.

[Richard1048576]

LGTM