fix(rocksdb): Detected interrupted trie update, but trie has idempotency

[AshinGau]

Background

After introducing RocksDB sharding(#225) support, the original assertion ck.block_number + 1 == block_number can no longer be guaranteed. This PR documents and handles this edge case.

Root Cause

With RocksDB sharding, trie updates and state updates now execute in parallel, while the trie checkpoint is recorded within the state. This creates a race condition:

1. Block H completes its trie updates and records the checkpoint
2. Block H's state updates are still in progress
3. If the program is killed at this point:
   • Both ExecutionCheckpoint and best_block_number remain at H - 1
   • Recovery will not be triggered (since checkpoint shows H - 1)

Why This Is Safe

Although the trie updates for block H were partially persisted in the previous run, this does not cause data corruption because:

1. Block consistency: The consensus layer will re-send block H, and it is guaranteed to be identical to the previously interrupted block H
2. Trie idempotency: The MPT (Merkle Patricia Trie) algorithm is idempotent — writing the same trie nodes multiple times produces the same result

Design Rationale

The two types of tables have different fault-tolerance mechanisms:

Table Type	Consistency Guarantee
State tables	Rely on checkpoint to ensure dense, sequential block increments
Trie tables	Rely on MPT algorithm's idempotency to tolerate duplicate writes

This difference is also why the checkpoint is stored within the state tables rather than the trie tables.

Changes

Changed the assertion to an informational log, since detecting ck.block_number + 1 != block_number is now an expected scenario after interrupted trie updates, not an error condition.