fix(persistence): use unwind commit order for remove_blocks_above

The persistence service was using `database_provider_rw()` for unwind
operations, which uses normal commit order (SF → RocksDB → MDBX).

This could cause crash-recovery issues:
1. Blocks are persisted to RocksDB history shards
2. Unwind is triggered (RemoveBlocksAbove)
3. RocksDB shards are truncated and committed
4. Crash occurs before MDBX commit
5. On restart, MDBX checkpoints show old state
6. Same blocks are re-persisted
7. append_storage_history_shard fails with UnsortedInput because
   the shard already contains those block numbers

Fix: Use `unwind_provider_rw()` which ensures MDBX is committed first,
so on crash recovery MDBX checkpoints correctly reflect the unwind state.

crates/engine/tree/src/persistence.rs

@@ -140,7 +140,10 @@ where
     ) -> Result<Option<BlockNumHash>, PersistenceError> {
         debug!(target: "engine::persistence", ?new_tip_num, "Removing blocks");
         let start_time = Instant::now();
-        let provider_rw = self.provider.database_provider_rw()?;
+        // Use unwind provider to ensure correct commit order (MDBX → RocksDB → SF).
+        // This prevents crash-recovery issues where RocksDB is committed but MDBX is not,
+        // which would leave stale block numbers in RocksDB history shards.
+        let provider_rw = self.provider.unwind_provider_rw()?;
 
         let new_tip_hash = provider_rw.block_hash(new_tip_num)?;
         provider_rw.remove_block_and_execution_above(new_tip_num)?;