0.16 consume exceeds the 90s offscreen write deadline and is killed

On the 0.16 line, a `consume` run inside the offscreen document exceeds the 90 s `WRITE_DEADLINE_MS` and is killed, so claiming fails. Two Local E2E specs fail on it (`recall-reclaim`, `send-private`), both via `claimAllNotes`.

### Symptom

```
Error: [WalletPage.claimAllNotes] timed out after 120000ms with 1 pending note(s)
Transactions: [{"id":"8c22f144","type":"consume","status":"Failed","stage":"sending",
"error":"OperationAbortedError: Offscreen operation … aborted (deadline)"}]
```

Three separate consumes, each `initiatedAt → completedAt` = **101 s** — i.e. they ran to the 90 s deadline plus teardown, rather than failing fast.

### Why this is only surfacing now

`pr-e2e-local` has **never completed a spec run on a 0.16 branch**. The 0.16 E2E stack landed in #521, but every run since died during node bring-up; #713 is the first to get the local node up, so this is the first time these specs have actually executed against 0.16. It is not a regression introduced by #713 — it is newly *visible*.

On `main` (0.15) the same specs pass with the same 90 s deadline and the same offscreen default (`vite.background.config.ts` sets `MIDEN_USE_OFFSCREEN_CLIENT` to `true`), so the deadline is adequate for 0.15 and not for 0.16 on this hardware.

### Ruled out

- The local node and remote prover both come up (`node(57291)+prover(50052) ready`).
- Networks resolve correctly: `MIDEN_NETWORK=localhost` → `LOCALNET` → prover `http://localhost:50052`.
- Not the note-transport binary-name break, which is fixed separately in #713.

### The open question

Whether 0.16 proving is genuinely slow enough to matter in production, or whether 101 s is an artifact of a 2-core CI runner. Recorded figures for 0.15 are ~40 s single-threaded in the service worker vs ~11 s multi-threaded offscreen on a 10-core machine; if 0.16 is 2–3× heavier, a fast machine still lands well inside 90 s while a CI runner does not.

That distinction decides the fix, so it should be measured before choosing:

- if it is CI-only, the deadline wants to be configurable (default 90 s, raised for the E2E build) so a slow runner stops reporting a false wedge;
- if real hardware also approaches 90 s, the deadline is mis-calibrated for 0.16 and would kill genuine consumes for Chrome users — the more serious case.

**Do not simply raise `WRITE_DEADLINE_MS`.** It exists to make a wedged offscreen op killable; widening it without knowing which case applies trades a visible CI failure for an invisible production hang.

The prove-timing telemetry added in #466 (and made realm-correct in #714) is the instrument for this — a consume on 0.16 with the offscreen client on, on both a CI runner and a developer machine.

Found while getting #713's Local E2E to run.