wallet: auto-reply over Tor when scanning an Invoice1 slatepack

[jwinterm]

Summary

Mirrors the existing Standard1 + Send-task flow for the invoice
direction. When a customer scans an Invoice1 slatepack QR with an
embedded sender address, the patched pay() forwards the sender
address through create_slatepack_message, and the OpenMessage
handler — if the wallet's Tor service is running or starting —
pushes the signed Invoice2 to the merchant's foreign-api
finalize_tx over Tor. The merchant's wallet finalizes and posts
on their side, so no local finalize/post is needed (cf. the
existing send_tor closure for Standard1, which does need that).

Closes the mobile-UX gap where a customer scanning a Grin invoice
QR had to manually copy the response slatepack from the wallet
and paste it back to the merchant's web/storefront. With this
patch, scanning an invoice QR is now a single tap: scan →
confirm → done.

What the patch touches

Single file, src/wallet/wallet.rs:

1. send_tor() gains a finalize: bool parameter that
   switches the JSON-RPC body between receive_tx (existing
   behavior for Standard1 send) and finalize_tx (new path for
   the invoice flow). Same Tor SOCKS plumbing handles both.

2. pay() gains a dest: Option<SlatepackAddress> parameter
   (mirroring receive()) and forwards it to
   create_slatepack_message. The on-disk response slatepack
   continues to be written, so paste-back is always available as
   a fallback.

3. handle_task gains a sibling pay_tor closure to
   send_tor, used in the OpenMessage::Invoice1 arm when the
   parsed slatepack has a sender address and the wallet's Tor
   service is running. Unlike send_tor, pay_tor does not
   finalize/post locally — the merchant does that on their side.

4. OpenMessage::Invoice1 arm passes dest.clone() to
   pay() and, when the wallet's Tor service is up + a sender
   address is present, awaits pay_tor() and returns. Otherwise
   falls through to the existing write-to-disk paste-back path
   unchanged.

Backward compatibility

• Slatepacks without an embedded sender address (older issuers,
  or anything that explicitly omits the field) fall through to
  the existing on-disk paste-back path. No regression.
• Tor send failures (no circuit, peer offline, onion unreachable)
  are logged and surface via on_tx_error + on_task_result.
  The on-disk response slatepack was already written before the
  Tor send was attempted, so the customer can always recover by
  pasting it back manually.
• No protocol change, no new dependencies, no new state to
  persist.

Privacy / security review

• The sender's slatepack address is already embedded in the
  slatepack by the issuer (it's how merchants identify which
  customer signed the response in any flow). Auto-using it for
  the reply doesn't reveal anything the merchant didn't already
  receive.
• Outbound Tor send to a slatepack-embedded onion is the same
  security surface as grin-wallet send -m tor -d <addr>. Same
  arti SOCKS5 proxy, same circuit semantics.
• No change to keystore, no change to identity.

Real-world validation

End-to-end working today on a production BTCPay deployment using
the Such-Software btcpayserver-grin-plugin v1.3.5 (released
2026-06-22). The merchant runs grin-wallet listen with a Tor
hidden service exposed; a patched Grim build on Android scans the
invoice QR, signs it, posts the Invoice2 over Tor, and the
merchant's BTCPay invoice settles after min_confirmations with
zero customer interaction beyond the initial scan.

The plugin-side counterpart picks up these payments by polling
the merchant wallet's tx_log for kernel_excess on the
invoice's recorded slate_id — an indicator that
finalize_tx already ran — and promotes the invoice through
its existing Broadcast → Confirmed → Settled state machine.
That work is independent of this PR and lives in the plugin,
but it's evidence the architecture works as designed.

Test plan

• Builds for Android arm64-v8a (scripts/android.sh build v8,
  Cargo profile release-apk)
• End-to-end Tor-finalize against a real merchant
  grin-wallet listen instance (mainnet)
• Paste-back fallback still works when Tor service isn't up
  (no behavioral change for that path)
• Standard1 + Send-task Tor flow unchanged (please verify in
  review — the only call-site change for that path is the
  false literal added to the existing send_tor invocation)

Happy to iterate on the approach or the naming — this is the
minimum-diff version, but I'm open to factoring it differently if
maintainers prefer.