Roll back `AccountSmtForest` on IndexedDB write failure in `IdxdbStore::apply_transaction`

Follow-up from 0xMiden/miden-client#2210 ([comment](https://github.com/0xMiden/miden-client/pull/2210#issuecomment-4659429821)).

0xMiden/miden-client#2210 fixed this for `SqliteStore`. `IdxdbStore::apply_transaction` has the same gap in its delta path: it mutates and stages the in-memory `AccountSmtForest` before writing the account delta to IndexedDB. If that write fails, the forest keeps the staged roots while the account tables don't get the update, and `apply_transaction` has no rollback/discard path (`discard_roots` only runs during sync), leaving the two inconsistent (same class as 0xMiden/miden-client#2181). The full-state path writes the account to IndexedDB before staging, so it isn't affected the same way.

https://github.com/0xMiden/web-sdk/blob/16ea4a45e726498adc4bc6fb3df1c7d26c08d3bc/crates/idxdb-store/src/transaction/mod.rs#L88

This needs a different mechanism than the SQLite fix though: `apply_transaction` isn't wrapped in a single outer IndexedDB transaction covering the transaction record, account state, notes, and tags (each helper is its own Dexie transaction), so the clone-then-swap approach of `with_forest_snapshot` can't be ported directly.

The issue is in `crates/idxdb-store/src/transaction/mod.rs` at line 88. Start by understanding the `apply_transaction` method and the `AccountSmtForest` staging logic. Compare with the SQLite fix in the linked PR. Investigate how IndexedDB transactions work in this codebase and design a rollback mechanism that ensures consistency between the forest and the account tables on write failure. Testing will involve simulating IndexedDB write failures.

由索引模型根据 Issue 内容生成。