feat(mobile): add send screen with recipient, asset, amount and memo inputs

[iredis]

Overview

This PR ports the web send page's multi-step state machine and input validation to React Native, building the entry point of the payment flow — the form where users choose a recipient, asset, amount, and memo, then move to a confirmation step. This lays the UI groundwork that signing (backlog #37) plugs into.

Related Issue

Closes #464

Changes

📦 New Files

• [ADD] frontend/mobile/app/(tabs)/send.tsx — Full send screen with 5-step state machine (form → confirm → signing → done → error):
  • Asset selector: chip-style picker for XLM + any Horizon balances
  • Recipient input: Stellar address field with QR scanner integration (uses new QrScanner component)
  • Amount input: decimal keyboard, Inconsolata monospace font
  • Memo field: optional text memo (max 28 chars)
  • Form validation: valid G…/C… address, positive amount, asset selected
  • Confirm step: card preview of recipient (truncated), amount, memo, network, auth method
  • Sign/Submit: builds classic payments or Soroban token transfers depending on address type; waits for RPC confirmation
  • Success/Error states: clear visual feedback with tx hash display
• [ADD] frontend/mobile/lib/storage.ts — In-memory storage abstraction (ready for expo-secure-store in production)

Verification

Acceptance Criteria	Status
Recipient/asset/amount/memo inputs with validation	✅ validateForm() checks address format, positive amount, and asset selection
Confirm step shows transaction details	✅ Card preview with truncated recipient, amount, memo, network, auth
Multi-step state machine works	✅ form → confirm → signing → done → error ported from web reference
QR scanner integration	✅ Recipient field has QR button that opens the QrScanner component

[vercel]

@iredis is attempting to deploy a commit to the miracle656's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@iredis 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

[Miracle656]

Thanks for this. Closing it — (tabs)/send.tsx has been built up by four PRs since you opened this, and a 721-line wholesale replacement would take most of that back out. There are two pieces here worth keeping though, and I'd like them as a smaller follow-up.

What's already on main

The send screen is now 209 lines and covers most of what this branch adds:

Capability	Landed in
Deep-link prefill of to / amount / asset / memo	#518, wired to /pay
Recipient validation (isValidDestination, StrKey checksum + federated)	#540
Contact picker	#538 / #540
QR scanning, including SEP-7 codes	#548
Submit gated on a valid recipient and a positive amount	#540

Merging this branch would replace all of it, and in particular would drop the prefill contract that /pay and the SEP-7 handler depend on.

lib/storage.ts can't ship

const store = new Map<string, string>();

export async function getItem(key: string): Promise<string | null> {
  return store.get(key) ?? null;
}

That's an in-memory map behind an async interface, and the comment is candid that it's a stand-in. Anything written is gone on reload, so any state depending on it silently resets. lib/walletStore.ts on main already covers this properly — expo-secure-store, so the fee-payer secret never lands in plain application storage.

What's genuinely missing and worth resubmitting

Two things from here have no equivalent on main, and both are squarely in #464's acceptance ("recipient/asset/amount/memo inputs with validation and a confirm step"):

1. The asset selector. Loading balances from Horizon and letting the user pick which asset to send — main hardcodes XLM unless a deep link says otherwise. Your Horizon balance parsing, including the asset_type === 'native' branch and building Asset(code, issuer) for issued assets, is the right approach.
2. The confirm step. main has a "Review" button that's wired to nothing. The Step = 'form' | 'confirm' | 'signing' | 'done' | 'error' machine the issue asks for is still unbuilt, and 42. Tx preview + detail sheets #470's TxPreviewCard (merged) is sitting there waiting to be the confirm screen's body.

A PR adding just those two on top of the current send.tsx would be a much smaller diff and would close #464 cleanly. Note getNativeAssetContractId() doesn't exist on main's lib/network.ts — it was in #547's version, which I closed for other reasons — so that needs adding as part of it, or replacing with Asset.native().contractId(networkPassphrase).

Happy to review that one.