feat: SDK hardening integration + MidenClient singleton unification

[WiktorStarczewski]

Summary

Integrates the SDK hardening improvements into the wallet and unifies the MidenClientSingleton from two instances (dispose-and-recreate per-tx) to one long-lived singleton with a late-binding keystore bridge. Net result: cleaner architecture, 2.5× faster sends, and robust error handling for partial-failure scenarios.

SDK hardening integration

Wallet-side integration for 5 SDK improvements (each has its own SDK PR):

1. Typed sign-callback failure recovery — when the wallet gets locked mid-transaction, the sign callback throws with { reason: 'locked' }. The TransactionProcessor reads midenClient.lastAuthError() and leaves the tx Queued for retry after unlock, instead of marking it Failed (which previously caused note loss).

   • SDK: 0xMiden/miden-client#2058

2. ApplyTransactionAfterSubmitFailed handling — when a tx submits on-chain but the local apply step fails, the wallet marks it Completed (not Failed) using the SDK's new errorCode dispatch. The user sees "Transaction sent" instead of a confusing "Transaction failed" for a tx that IS on chain.

   • SDK: 0xMiden/miden-client#2059, 0xMiden/miden-client#2060

3. Private-note transport retry — if the P2P blob delivery fails after a private send commits on-chain, the wallet marks the note transportPending and retries via resendPrivateNoteById() with exponential backoff in the background.

   • SDK: 0xMiden/miden-client#2061

4. WASM call serialization + waitForIdle — the wallet's lock() action uses waitForIdle() to drain in-flight WASM operations before clearing the vault key, preventing the sign-callback race that caused 7/7 executeTransaction errors in stress testing.

   • SDK: 0xMiden/miden-client#2057 (draft — exploratory)

MidenClient singleton unification

Collapses MidenClientSingleton from two instances (instance + instanceWithOptions) to one long-lived singleton:

• New keystore-bridge.ts — pure callback-slot module (activeInsertKey + activeSignCallback). The SDK's permanent keystore callbacks delegate to these mutable slots.
• New keystore-wiring.ts — subscribes to Effector unlocked/locked events and re-points the bridge's insert-key slot to the active vault's encryptKeystoreEntry method. Called from all 3 entry points (SW main.ts, mobile-adapter.ts, desktop-adapter.ts).
• Vault.encryptKeystoreEntry() — new method that encrypts a keypair under the vault's KEK without exposing the key outside the Vault class.
• getMidenClient() no longer accepts options — tests that need a specific seed call MidenClientInterface.create({seed}) directly.
• Wallet mutex stays active as belt-and-suspenders (pending SDK-side exploration in #2057).
• withProverFallback uses defaultProver path — relies on the SDK's proveTransactionWithProver(&prover) by-reference fix (#2062) to keep the JS prover handle alive across calls.

Performance

The singleton eliminates the per-tx client dispose-and-recreate cycle (~1-3s overhead per send). Combined with the by-reference prover fix:

Metric	Before (dispose-recreate)	After (singleton)
Public send	~3.2s	~1.4s
Private send	~8.5s	~2.2s
Conservation	✓	✓

Stress test results

• 5-op validation with singleton + by-reference prover: all ops ~1.3-2.2s, 0 failures, conservation held
• 30-op bisect validation (pre-singleton, pre-flight revert): 30/30, delta=0

SDK dependencies

This PR depends on the following SDK changes (all on 0xMiden/miden-client):

SDK PR	Status	Required for
#2058	Open	lastAuthError() — typed sign failure recovery
#2059	Open	ApplyTransactionAfterSubmitFailed error variant
#2060	Open	errorCode dispatch (depends on #2059)
#2061	Open	resendPrivateNoteById() transport retry
#2062	Open	proveTransactionWithProver(&prover) by-reference fix
#2057	Draft	waitForIdle() + WASM serialization (exploratory)

The wallet's @miden-sdk/miden-sdk dependency uses file:../miden-client/crates/web-client during development. Once the SDK PRs land and a release is cut, the wallet will pin to the published version.

Files changed

New files (3):

• src/lib/miden/sdk/keystore-bridge.ts — callback-slot bridge module
• src/lib/miden/sdk/keystore-bridge.test.ts — 12 unit tests
• src/lib/miden/back/keystore-wiring.ts — Effector event wiring

Modified files (14):

• src/lib/miden/sdk/miden-client.ts — singleton simplification
• src/lib/miden/sdk/miden-client-interface.ts — drop keystore options, wire bridge, defaultProver path
• src/lib/miden/sdk/miden-client.test.ts — remove dispose-recreate test
• src/lib/miden/sdk/miden-client-interface.test.ts — update for bridge wiring
• src/lib/miden/back/vault.ts — encryptKeystoreEntry, persistKeystoreEntry helper, export storage keys
• src/lib/miden/back/vault.test.ts — round-trip test for encryptKeystoreEntry
• src/lib/miden/back/actions.ts — lock comment update
• src/lib/miden/back/dapp.ts — comment clarifying signData is not in bridge path
• src/lib/miden/back/main.ts — wireKeystoreBridge before intercom
• src/lib/miden/back/main.test.ts — mock keystore-wiring
• src/lib/miden/activity/transactions.ts — bridge sign callback with try/finally
• src/lib/intercom/mobile-adapter.ts — wireKeystoreBridge in init
• src/lib/intercom/mobile-adapter.test.ts — mock keystore-wiring
• src/lib/intercom/desktop-adapter.ts — wireKeystoreBridge in init

Test plan

• yarn lint && yarn format — clean
• yarn test — 1661/1661 pass
• 5-op stress with singleton + by-reference prover: all ops ~1.3-2.2s
• 30-op bisect: conservation held (delta=0)
• Mobile smoke: onboarding + send + lock/unlock cycle
• Desktop smoke: same checklist

[0xnullifier]

The singleton eliminates the per-tx client dispose-and-recreate cycle (~1-3s overhead per send). Combined with the by-reference prover fix:

Does it ? I mean surely not doing a simple console.time around like this

export async function getMidenClient(options?: MidenClientCreateOptions): Promise<MidenClientInterface> {
  if (options) {
    console.time('Creating MidenClient with options');
    const client = await midenClientSingleton.getInstanceWithOptions(options);
    console.timeEnd('Creating MidenClient with options');
    return client;
  }
  console.time('Getting MidenClient instance');
  const client = await midenClientSingleton.getInstance();
  console.timeEnd('Getting MidenClient instance');
  return client;
}

it consistently takes less than 50ms so idk if this unification does anything in that regards and if it does take 1-2s just to create the client and destroy instance then there is bigger fish to fry