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 the 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. 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)

Note: an earlier revision of this PR added wallet-side machinery for private-note transport retry (transportPending flag + retryPendingTransports background loop calling resendPrivateNoteById). That has been dropped — superseded by 0xMiden/miden-client#2127's durable NTL outbox at the SDK layer. Original PRs (0xMiden/miden-client#2061, 0xMiden/web-sdk#26) are closed.

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	✓	✓

[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

[WiktorStarczewski]

Cleanup landed: 665a2b697 drops the wallet-side transport-retry machinery now that miden-client#2127's durable NTL outbox handles delivery at the SDK layer. Removed: transportPending/transportAttempts/transportLastAttemptAt fields, retryPendingTransports() + retryPendingTransportsImpl() + backoff constants (~90 LOC in transactions.ts), the TransactionProcessor calls, the describe('retryPendingTransports') test block + 2 transportPending tests in completeSendTransaction (~140 LOC in transactions.branches.test.ts), and the CHANGELOG entry. Two replacement tests cover the Completed-without-transportPending semantics on both sendPrivateNote-throws and lock-rejects branches.

Net: 7 files changed, 45 insertions / 347 deletions. All 740 src/lib/miden/** tests pass, lint clean, ts clean. Description updated to drop the section-3 narrative.

Related closures: miden-client#2061 (PR), web-sdk#26 (companion PR), web-sdk#124 (source issue) — all closed with reasoning that points at #2127.

[WiktorStarczewski]

Superseded by #268, a thinned-down version containing only the SDK-hardening improvements backed by external PRs (sign-callback recovery → miden-client#2058; ApplyTransactionAfterSubmitFailed → #2059/#2060; tx-stage UI; stress transport perturbation → #2127). The MidenClient singleton unification and item 3 (waitForIdle, draft #2057) are dropped, and the client singleton is left untouched. Closing in favor of #268.