feat: browser-extension wallet approval via loopback signing bridge

[Nic-dorman]

Summary

Adds a third way to approve upload payments alongside the WalletConnect QR and mobile flows: a browser-extension wallet (MetaMask, Rabby, …) on the same computer. Extensions can't run inside the Tauri webview, so the app runs a loopback signing bridge (Truffle-Dashboard pattern):

• src-tauri/src/wallet_bridge.rs — axum server bound to 127.0.0.1:17423 (stable port, so the wallet's per-site approval survives across sessions), serving a single-file signing page plus two relay endpoints. Hardening: per-session 256-bit bearer token carried in the URL fragment (never on the wire, no Referer leakage), constant-time token comparison, exact Host allowlist (DNS-rebinding defense), loopback Origin required on state-changing POSTs, no CORS ever emitted, strict page CSP.
• src-tauri/bridge-page/index.html — EIP-6963 wallet picker + long-poll relay: forwards EIP-1193 requests to the injected provider and posts answers back. Remembers the chosen wallet, warns before closing mid-approval.
• utils/wallet-bridge-connector.ts — wagmi connector rendered as a "Browser extension" card in the existing connect modal; relays every wallet request over Tauri IPC to the bridge. utils/payment.ts and the payment flow are unchanged.

Lifecycle safety

Closing the signing tab cannot strand a payment:

• a request arriving with no live page reopens the page automatically (debounced, retried by a session watchdog — survives a dropped tab-close beacon and browser tab-sleep);
• requests the page had already handed to the wallet fail fast with a "check your wallet before retrying" error and are never re-sent (the wallet may still execute the first copy — resending could double-pay);
• bridge_stop / bye unblock all in-flight requests immediately instead of waiting out timeouts.

Also in this PR

• Windows test executables died at load (STATUS_ENTRYPOINT_NOT_FOUND): rfd/muda's TaskDialogIndirect import is comctl32-v6-only and tauri-build's manifest only reaches bin targets. Fixed by delay-loading comctl32 in build.rs.
• Payment errors now render viem's one-line shortMessage (rejections: "Cancelled in your wallet") instead of the full multi-line diagnostic dump, which overflowed the file row and toast. Full dump still goes to the devtools console.

Testing

• Rust 13/13 — 7 wallet_bridge tests: token uniqueness, constant-time compare, Host/Origin/token guards, request/response roundtrip, stop-unblocks-inflight, bye fail-fast for claimed and queued requests.
• Vitest 58/58 — includes 8 connector tests.
• Manual on Windows against the live network:
  • connect → default browser opens the signing page, extension connect prompt fires
  • pay with the page open → approval appears straight in the extension
  • pay with the page closed → page reopens itself, extension approval window opens
  • reject in the wallet → one-line "Cancelled in your wallet" error

Size cost measured earlier on release builds: +1.25 MB exe (axum/tower stack), est. ~+0.4–0.5 MB on the MSI; frontend ~2 KB gz.

Follow-ups (not in this PR)

• "Reopen approval page" affordance + paying-badge copy driven by bridge_status
• Cancel-during-payment UX (safe for queued requests; warn for claimed)
• i18n for the signing page / new error strings
• macOS/Linux manual verification (bridge is platform-neutral but only Windows was tested end-to-end)

🤖 Generated with Claude Code

[dirvine]

Review — hold before merge

Reviewed exact head a15b6dc94223b90d7ebdff6b7e602e8169a80387.

Material lifecycle blocker: normal slow approvals are treated as a dead page

signer_requests stamps last_signer_poll and hands the request to the page (src-tauri/src/wallet_bridge.rs:377-390). The page then waits inside active.provider.request(...) (src-tauri/bridge-page/index.html:284-302) and does not issue another long-poll until the wallet answers.

After 35 seconds without another poll, the five-second watchdog calls fail_claimed (src-tauri/src/wallet_bridge.rs:522-526). That therefore fires during an ordinary human-paced approval, not only when the page has died. The app receives code 4900 and marks the payment failed, while the original wallet prompt remains live. If the user approves afterwards, /signer/response gets 410 because the pending slot was removed; retrying from the failed row can submit another payment although the first transaction may have landed.

I reproduced this on the exact head with a temporary regression test:

1. enqueue eth_sendTransaction;
2. GET /signer/requests so the page claims it;
3. wait SIGNER_LIVENESS_WINDOW + 10s without bye, simulating a live page awaiting the wallet;
4. assert the waiter is still pending.

Result: failed after 45.03s — the waiter had already been terminated by the watchdog. The temporary test was removed and the worktree returned clean.

Required invariant: a claimed request must not be failed solely because the request-poll timestamp is stale while the page is awaiting provider.request. Use a liveness signal independent of the single poll loop, or let the existing claimed-request/RPC deadline govern this state. Please add a regression test that waits beyond the liveness window and then proves the response is still accepted with 204 and delivered to the app.

Current CI blockers

• utils/wallet-bridge-connector.ts:67 — connect does not satisfy wagmi's generic withCapabilities return contract; nuxi typecheck fails with TS2322.
• src-tauri/src/wallet_bridge.rs:900 — cargo fmt --check fails on the single-line assertion.

Verified

• npm test -- --run — 58/58 passed.
• cargo test --manifest-path src-tauri/Cargo.toml wallet_bridge --lib --no-fail-fast — 7/7 passed with the CI-style local sidecar stub.
• GitHub rust (build) and rust (clippy) — passed.
• Loopback bind, token, Host/Origin, no-CORS and late-response controls otherwise look sound; no standalone security blocker found.

Please hold merge until the watchdog defect and the two red CI gates are fixed.

[Nic-dorman]

@dirvine Thanks — the watchdog finding was exactly right, and reproducing it against a live page past the window made the failure mode unambiguous. All three items are addressed as of fd4c685:

Watchdog defect → fixed in 4678339 with a dedicated liveness channel. The request long-poll can't double as the liveness signal — it blocks inside provider.request for as long as a human ponders the prompt. The page now keeps one GET /signer/ping parked at the server at all times (stamped on entry; park paced at 20s, comfortably inside the 35s window; a pure awaited fetch, so background-tab timer throttling can't starve it; the park races session shutdown so a stopped session doesn't linger on open handlers). Liveness is now polls or pings: the watchdog only fails claimed requests when both loops have gone quiet — an actual page death (crash, tab-sleep) — and the explicit bye path is unchanged.

Your required invariant is a permanent regression test, slow_wallet_approval_survives_liveness_window: claim the request → request loop silent for ~3 liveness windows while pings continue → assert the waiter is still pending → POST the wallet's answer → assert 204 and the result delivered to the app. Timing knobs are injectable (SessionTuning), so it runs in ~1.5s instead of 45. The counterpart watchdog_fails_claimed_request_when_pings_stop pins the prompt fail-fast when pings stop too.

TS2322 → fixed in fd4c685. connect() now honors wagmi's withCapabilities conditional return (address + capabilities records when set), using the same cast wagmi's own connectors employ. nuxi typecheck exits 0. (Same commit also excludes src-tauri/target from vue-tsc's sweep — local release builds leave binary codegen assets named *.js that drowned local typecheck output; CI never sees them.)

cargo fmt → clean (folded into 4678339).

Local state on the new head: Rust 15/15 (9 wallet_bridge tests including the two new liveness ones), Vitest 58/58, typecheck clean. CI is re-running now.

🤖 Generated with Claude Code