Emit a callback/event when ensureClientVersion resets the IndexedDB store, so embedders can react

## Background

`ensureClientVersion` in [`crates/idxdb-store/src/ts/schema.ts#L548-L591`](../blob/main/crates/idxdb-store/src/ts/schema.ts#L548-L591) silently closes, deletes, and reopens the entire IndexedDB store whenever the persisted client version crosses a major or minor semver boundary (or either version is unparseable). The behaviour itself is acknowledged and intentional today — the comment block at [`schema.ts:413-451`](../blob/main/crates/idxdb-store/src/ts/schema.ts#L413-L451) states migrations are deferred until the network stabilises, and #80 / #125 track making migrations real. So this isn't a request to change the nuke itself.

What's missing is any signal to the embedder that it happened. Today the only output is `console.warn("IndexedDB client version mismatch...")` ([`schema.ts:584`](../blob/main/crates/idxdb-store/src/ts/schema.ts#L584)). Apps embedding the SDK — wallets, dapps, anything with its own keystore-adjacent UI — cannot:

- warn the user that their local state was reset,
- trigger a re-import / re-sync flow,
- emit telemetry that a wipe happened,
- distinguish a fresh install from a post-nuke state.

For an MV3 background extension that auto-updates on a schedule, this means a user can open their wallet one day, find their local store nuked by an SDK bump, and have no visible explanation in-app. (Real-world data point: a pioneer recently reported "history visible, balance zero" after a wallet restore + auto-update; even though their actual root cause turned out to be a separate wallet-side regression, the absence of any signal here made the nuke a plausible suspect we couldn't rule in or out without reading the SDK source.)

## Problem

1. No callback, event, or return-value channel that fires when the wipe runs.
2. No way to read post-hoc whether the current opening followed a wipe (e.g. a settings flag or a separate getter).
3. Embedders consequently can't follow the rule the code comment itself implies: "the network reset means you should re-import from the node."

## Proposed Solution

One of (in increasing order of invasiveness):

- Add an `onStoreReset?: () => void | Promise` option to `openDatabase(network, clientVersion)` that fires on the close-delete-reopen path. Backwards-compatible.
- Emit a custom event (e.g. `MidenDatabase.dispatchEvent(new Event('store-reset'))`) on the `MidenDatabase` instance so multiple listeners can subscribe.
- Persist a one-shot "last_reset_at" record in `Settings` so embedders can detect the reset on the *next* open, after the listener wiring has run.

Any of the three works. The callback form is the smallest API surface and the easiest to consume from a React provider.

This is genuinely orthogonal to #80 (improving migration mechanisms) and #125 (migration tests) — those address making the wipe go away. This addresses the gap until they do.

Happy to send a PR if there's a preferred shape.

The issue points to the `ensureClientVersion` function in `crates/idxdb-store/src/ts/schema.ts`. Start by understanding the existing store reset logic around lines 548-591. The goal is to add a callback, event, or persistent flag that signals when a reset occurs. Check how `openDatabase` is called and what options it accepts. Look for existing event patterns or settings storage in the codebase to follow consistent conventions. A successful change will let embedders react to the reset without altering the wipe behavior itself.

Escrito por el modelo de indexación a partir del texto del issue.