Consuming a note against an imported public account fails at apply with "account data wasn't found" under the default Web Worker client

## Issue Description

When the WebClient runs with the Web Worker shim (the default, `useWorker: true`), submitting a transaction against a **public account that this client imported** (via `importAccountById`) rather than created fails at the apply step with `storage error: account data wasn't found for account id ...`. Reads of the same account (`getAccount`, `storage().getMapItem`) succeed, so the account is clearly in the store; only the apply fails.

My concrete case: a public `NoAuth` counter account is deployed on testnet by a separate client. In the browser I import it (`importAccountById`), read its storage fine, publish an increment note from a throwaway local sender, then consume that note as the counter. The consume executes and proves fine, then throws when applying the result. Creating an account locally and transacting on it works; only imported (existing, nonce > 0) accounts hit this.

Setting `useWorker: false` on the client makes the exact same flow succeed, which is my current workaround.

## Reproduction Steps

The flow needs a public account this client did not create (so `apply_transaction` takes the delta path rather than the full-state path). Sketch:

```js
const client = await WebClient.createClient(rpcUrl); // default: useWorker true
const counterId = AccountId.fromHex("0x..."); // public account NOT created by this client

await client.importAccountById(counterId);
await client.syncState();
await client.getAccount(counterId); // OK: reads succeed

// ... publish a note from a local sender, wait until it is consumable for counterId ...
const req = client.newConsumeTransactionRequest([note]);
await client.submitNewTransaction(counterId, req); // throws at apply
```

Workaround: `WebClient.createClient(rpcUrl, undefined, undefined, undefined, undefined, /* useWorker */ false)` (or `MidenProvider config={{ useWorker: false }}` via `@miden-sdk/react`), and the identical flow applies cleanly.

## Error Output

```
WebClient: Error from worker in submitNewTransaction: Error: failed to apply transaction result: storage error: account data wasn't found for account id 0x4dcaee76ffebfc511e06582702289d
at miden_client_web::js_error_with_context
at miden_client_web::new_transactions::::apply_transaction::{{closure}}
at wasm_bindgen_futures::future_to_promise::{{closure}}::{{closure}}
```

## Environment Information

- `@miden-sdk/miden-sdk`: 0.15.3 (single-threaded `st` build)
- `@miden-sdk/react`: 0.15.3 (client created via `MidenProvider`)
- Browser: Chrome, `crossOriginIsolated === true`, worker enabled
- Network: testnet, remote prover `tx-prover.testnet.miden.io`

## Key Question

My reading of the flow (from `crates/idxdb-store/src/transaction/mod.rs` and the store's SMT forest): `apply_transaction` on an existing (nonce > 0) account takes the delta path, which looks the account's roots up in the executing instance's in-memory SMT forest. Under the worker there appear to be two forests (one main thread, one worker) over the same IndexedDB, and `importAccountById` registers only the main-thread forest while apply runs in the worker, whose forest was built at construction and never receives the late-imported counter. Is transacting on an imported public account meant to work with the worker shim, and if so should `importAccountById` register (or the worker rebuild) the worker's forest? Happy to share a full repro repo if useful.

The issue is in the Web Worker shim's handling of imported public accounts. Start by examining the IndexedDB store in crates/idxdb-store/src/transaction/mod.rs and the SMT forest synchronization between main thread and worker. The worker's forest may not be updated after importAccountById. Look at the WebClient's apply_transaction path for existing accounts (nonce > 0) and compare the worker vs. single-threaded flows. A full repro is needed to verify the hypothesis.

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