apply_state_sync delta path mutates SMT forest without rollback on IndexedDB write failure

## Bug

`apply_state_sync` in `crates/idxdb-store/src/sync/mod.rs` uses `replace_roots` (immediate mutation) on the SMT forest when applying public account delta updates. If the subsequent `apply_transaction_delta` IndexedDB write fails, the SMT forest is already mutated while the persisted data is stale.

Unlike the transaction path (`apply_transaction`/`apply_transaction_batch_atomic`), which uses `stage_roots`/`commit_roots`/`discard_roots`, the sync delta path mutates the forest inline via `replace_roots` with no rollback mechanism:

```rust
// From sync/mod.rs — delta path
smt_forest.replace_roots(...) // immediate mutation
// ... then writes to IndexedDB
apply_transaction_delta(...) // If this fails, forest is already inconsistent
```

## Impact

- SMT forest (in-memory) diverges from IndexedDB (persisted)
- Future SMT witness computations produce wrong results
- Account storage/vault verification fails
- Inconsistency persists until client reset and full re-sync

## Root cause

`replace_roots` mutates the forest immediately instead of staging the changes. Compare with the transaction path which properly stages first and only commits after DB success.

This is the same class of bug as #190 (apply_transaction rollback), but in the sync code path rather than the transaction code path.

The bug is in `crates/idxdb-store/src/sync/mod.rs` in the `apply_state_sync` function. Start by reading the code around `replace_roots` and comparing it to the transaction path's `stage_roots`/`commit_roots`/`discard_roots` pattern in the same codebase. Understand how IndexedDB writes are performed and how failures are handled. 'Done' looks like modifying the sync path to stage changes and roll back on DB write failure, ensuring the SMT forest and persisted data remain consistent.

Scritto dal modello di indicizzazione a partire dal testo della issue.