perf: run transaction batches in the worker instead of the main thread

[WiktorStarczewski]

Closes #312.

Batching proved every transaction on the main thread while single submits offloaded to the Web Worker, so a large batch froze the UI for its full duration. This routes the batch call through the worker like every other write.

What changed

submitNewTransactionBatch reached the worker shim only through createClientProxy's fallback, which runs the call on the main-thread WASM instance. It is now an explicit method on WebClient that forwards to the worker, with a MethodName entry and a handler on the worker side. One batch call executes and proves every transaction plus the batch proof, so this is the single longest-running WASM call the SDK makes.

MockWebClient deliberately keeps batching on the main thread. Mock submits round-trip the serialized mock chain through the worker, but MockChain's serializer does not write pending_batches and its deserializer resets the field to empty — so forwarding a mock batch would discard it while the shared store had already recorded its per-transaction updates, advancing the nonce on a chain that never saw the batch. Mock clients exist for tests, where a blocked main thread costs nothing.

Request bytes are normalized once on the main thread, ahead of the worker/in-thread branch, so both paths accept exactly the same input. normalizeSerializedRequests lives in js/utils.js and is unit-tested.

Behaviour notes

• A free main thread is not a concurrent client. The call holds _serializeWasmCall for the whole round trip, so reads, syncs, and other forwarded methods still queue behind it. What changes is that the page keeps painting.
• Building the requests still happens on the main thread; the builders are SYNC_METHODS.
• With useWorker: false batching still runs in-thread, exactly as before.
• Batching becoming a forwarded method carries two consequences shared with every other forwarded method: external-keystore signature callbacks now sit behind the worker's 30s-per-callback ceiling, and lastAuthError() no longer reports a failed batch's auth error.

Documentation corrections

Review turned up several public claims about batching that were simply wrong, all corrected here:

• The returned number is the node's chain tip as of submission, not the block the batch commits in. Seven surfaces said the opposite, and waitForConfirmation polls against it — so it confirms only that the client caught up to the submission point. Behaviour is unchanged; the docs were wrong. Filed as batch waitForConfirmation is broken two ways: wrong target height, and it calls a method that does not exist #314.
• Batches always prove locally: the V1 batch API takes no prover, so ClientOptions.proverUrl applies to submit() but not to batching. The public docs said the opposite: the resource JSDoc claimed the batch used the client's configured prover, and the submitBatch JSDoc listed a prover setting that was never declared.
• The same-account rule is this wrapper's constraint, not the Rust client's — BatchBuilder::push takes an account per request.
• Mixing accounts does not throw, as the docs claimed. A TransactionRequest carries no account at all, so there is nothing per-operation to conflict with the batch-level account.
• Anchored the batch atomicity guarantee to its source. Review twice argued from miden-client's per-transaction sealing language that a batch is not all-or-nothing on chain; the node's own RPC contract settles it the other way (miden-node-proto-build 0.16.0-rc.1, rpc.proto:61: "All transactions in this batch will be considered atomic, and be committed together or not all"). The docs now quote it, so the claim stops being re-derived from the wrong layer.

Tests

• 13 unit tests for normalizeSerializedRequests, including cross-realm views and a prefix view that pins the half of the copy condition nothing else covered (verified by applying the mutant).
• batch.browser.test.ts spies on Worker.prototype.postMessage and asserts the batch is forwarded. It was in no shard, so CI never ran it; it is now in ci-shard-1-tx-flows.
• miden_client_api.test.ts asserts the mock batch is not forwarded, with syncStateMock as a positive control so the assertion cannot pass vacuously.

Unit suite: 399 passing.

Deliberately not fixed here

• Two defects in the worker's external-keystore callback bridge (Worker callback bridge: non-Error throws are silently treated as success, and the 30s ceiling is not configurable #316). A rejection thrown as a non-nullish value with no truthy .message — a bare string, or a wallet-style { code: 4001 } — loses its reason: the bridge sends error.message, the worker reads the resulting undefined as success and resolves undefined, and Rust then rejects it with the generic sign callback must return a Uint8Array — so a user rejection surfaces as what looks like a bug in the consumer's callback. And the 30s per-callback ceiling is fixed, which batching sharpens: signing happens at push time and this wrapper treats a failed push as fatal, so one slow hardware-wallet approval fails the whole batch. Both live in the bridge shared by every worker-forwarded method, so a batch-scoped fix would leave the other ~40 broken — same reasoning as A dead or erroring Web Worker leaves the client permanently wedged #315.
• A dead or terminated worker wedges the client (A dead or erroring Web Worker leaves the client permanently wedged #315). Batching now joins the set of methods affected by this, but it is the shared worker lifecycle for all ~40 forwarded methods and needs a terminal failure state, not a flush. A version scoped to batching alone would leave the other methods silently broken.
• waitForConfirmation is broken on batches (batch waitForConfirmation is broken two ways: wrong target height, and it calls a method that does not exist #314). Two separate defects: its poll calls syncStateWithTimeout, which does not exist anywhere in the crate, so it cannot advance the sync height and times out; and even once that is fixed it would only confirm the client reached the submission tip, not that the batch committed. Review also found that the unit test covering it invents the missing method on its mock and then asserts it was called, which is why it passed. All of that is reported on batch waitForConfirmation is broken two ways: wrong target height, and it calls a method that does not exist #314. This PR documents the option as broken across every public surface and drops it from both examples, but does not fix the code — it is pre-existing and #waitForBlock is not on the batching path this PR changes.