feat: send form validation, pending states, claim-link success screen, and QR code

[A6dulmalik]

Summary

Implements four related send-flow improvements from the Stellar Wave Program batch (issues #420–#423), each as its own commit:

• Send form input validation for amount and destination #420 — Amount validation: the details step now rejects amounts below 1 stroop (0.0000001, Stellar's smallest unit) and amounts with more than 7 decimal places, both with clear inline messages.
• Send flow loading and pending transaction states #421 — Pending/loading states: a distinct status banner (separate from the existing button-label text) now shows during preparing / awaiting-Freighter / submitting, transitions to a "pending confirmation" framing after ~4s, and shows a reassurance message if the wait passes ~12s. The submit button was already disabled during this window; that behavior is preserved.
• Send flow success screen with shareable claim link #422 — Success screen claim link: the success screen now shows the full claim URL in a dedicated box, a one-click "Copy link" button, and the claim link's absolute expiration deadline (not just relative "7 days" phrasing).
• QR code generation for claim links #423 — QR code: a new ClaimQrCode component renders a genuinely scannable QR code (via the qrcode package, 100% client-side, no network calls) for the claim link, with a download button and descriptive accessible alt text.

#420 — not fully closed, see below

The issue's third criterion ("invalid Stellar destination format rejected before submission") does not apply to this form. Per the product's own FRD (docs/bridgelet-frd-ui-ux.md) and the app's ephemeral-account/claim-link model, the sender never enters a recipient wallet address on /send — that's collected from the recipient during claim, where it's already validated (components/claim-status-card.tsx, components/wallet-address-input.tsx). Client-side "amount vs. sender balance" validation is also out of scope: the frontend has no wallet-balance-fetching capability today (no Horizon/account-balance call anywhere in lib/), and implementing one would be a separate, larger feature. I implemented the parts of #420 that do apply (minimum amount, decimal precision) and am flagging the rest rather than guessing at a bigger redesign.

Pre-existing issues found (not fixed here, out of scope)

While validating this branch I found main is currently broken independent of this PR:

• frontend/lib/create-bridgelet-client.ts, components/auto-sweep-retry.tsx, components/education-tooltip.tsx, components/mobile-deep-link.tsx, and components/multi-step-progress.tsx contain literal escaped-backtick sequences (e.g. \`${x}\` instead of an actual template literal) that fail to parse under both TypeScript and esbuild. This breaks npm run typecheck, npm run build, and any test that transitively imports create-bridgelet-client.ts (confirmed via git diff origin/main — these files are untouched by this branch).
• frontend's package-lock.json is out of sync with package.json (a peer-dependency conflict between @storybook/nextjs-vite@^10.4.6 and @chromatic-com/storybook@^3.2.0, which peer-depends on Storybook 8), so plain npm ci/npm install fails with ERESOLVE. This matches Frontend CI's current failing status on main (confirmed via gh run list).

Given the "no drive-by refactors" scope for this PR, I did not fix these — flagging for maintainer awareness since they block CI/build entirely regardless of this PR.

Dependency change

Added qrcode (runtime) + @types/qrcode (dev) to frontend/package.json for #423. frontend/package-lock.json was intentionally left unmodified — because of the pre-existing peer-dependency conflict above, regenerating it locally (even with --legacy-peer-deps) rewrites ~2,800 unrelated lines as npm re-resolves the whole tree differently, which would be a huge, unreviewable, out-of-scope diff. Once a maintainer resolves the underlying Storybook/Chromatic version conflict, regenerating the lockfile with qrcode included will be a small, clean diff.

Checks run

• npx eslint <changed files>: 0 errors, 2 pre-existing-pattern warnings (no-img-element on the new <img>, and a pre-existing exhaustive-deps warning on a hook I didn't modify).
• npm run lint (whole repo): 5 errors, all in the pre-existing broken files listed above — none in files this PR touches.
• npx tsc --noEmit (whole repo): same pre-existing files fail to parse; no errors involving any file this PR touches.
• npx vitest run components/send-form/: 61 passed, 2 failed. Both failures are confirm-step.test.tsx (mine and a stale duplicate under test-result/) failing to even transform, because they transitively import the corrupted create-bridgelet-client.ts above — not a logic failure in this PR's code. details-step.test.tsx (10/10) and claim-qr-code.test.tsx (3/3), which don't hit that import path, pass cleanly, using the same mocking patterns.
• npm run build: fails for the pre-existing reasons above (confirmed reproducible on a clean origin/main checkout of the same file).
• npm ci / npm install: fails for the pre-existing lockfile conflict above; used npm install --legacy-peer-deps locally to get a working node_modules for the checks above.

Test plan

• Unit tests added for amount validation (details-step.test.tsx)
• Unit tests added for pending states and button disabling (confirm-step.test.tsx)
• Unit tests added for claim link display, copy button, and expiry deadline (confirm-step.test.tsx)
• Unit tests added for the QR code component (claim-qr-code.test.tsx)
• Manual scan test of the generated QR code — not possible in this environment; the qrcode package is a widely-used, spec-compliant encoder, but a maintainer should verify a real scan on a device before merge

Closes #421
Closes #422
Closes #423
Closes #420

[drips-wave]

@A6dulmalik Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@A6dulmalik is attempting to deploy a commit to the aminubabafatima8-gmailcom's projects Team on Vercel.

A member of the Team first needs to authorize it.

[phertyameen]

Merged to \main\ as part of a consolidated integration (branch \merge-final, now pushed as commit \5155235\ on main).

Validation on main:

• Frontend CI: green
• Lighthouse CI: green
• Mobile CI: Lint & Type Check, Unit Tests, and Android/iOS prebuild all green

Note: the Mobile CI Android/iOS native debug build jobs still fail on pre-existing repo issues unrelated to this PR (react-native-reanimated vs RN 0.81 compile error, and the macos-14 runner's Xcode 15.4 vs RN's required Xcode >= 16.1). Tracked as follow-up work, not blocked by this change.