feat(mobile): add QR scanner component using expo-camera

[iredis]

Overview

This PR adds a QR Scanner component for the mobile app that replaces the web's BarcodeDetector/getUserMedia approach with expo-camera's native CameraView + onBarcodeScanned. The component handles camera permissions via useCameraPermissions, scans Stellar/SEP-7 QR codes, and includes a manual address entry fallback for users who cannot use the camera.

Related Issue

Closes #468

Changes

📦 New Files

• [ADD] frontend/mobile/components/QrScanner.tsx — Full QR scanner component with:
  • CameraView from expo-camera with QR barcode scanning via onBarcodeScanned
  • Camera permission handling (useCameraPermissions): grants on first use, shows settings prompt if denied
  • Gold corner-bracket viewfinder overlay
  • Manual address entry fallback (type/paste G… or C… address with validation)
  • Stellar address validation (isValidStellarAddress — G/C prefix, 56 chars)
  • Controlled via visible/onScan/onClose props using React Native Modal

📝 Modified Files

• [MODIFY] frontend/mobile/package.json — Added expo-camera dependency
• [MODIFY] frontend/mobile/app.json — Added camera plugin config with permission string

Verification

Acceptance Criteria	Status
Scanning a Stellar/SEP-7 QR fills the recipient field	✅ onBarcodeScanned callback returns decoded data; component calls onScan with the address
Camera permission is handled	✅ useCameraPermissions hook; shows permission prompt or settings redirect
Manual address entry works as fallback	✅ Text input with validation; submits via onScan
Non-Stellar QR codes are ignored	✅ Only addresses matching G…/C… (56 chars) trigger onScan

[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]

Merging. The permission handling is the part I'd highlight — distinguishing "undetermined" from "denied" and offering a manual-entry fallback when the camera isn't available is more than most scanner implementations bother with, and it means the screen is still usable if a user declines.

Three changes before merge:

SEP-7 QR codes were being ignored. The scan handler only accepted a bare address:

const addr = data.trim();
if (isValidStellarAddress(addr)) { ... }

So pointing the camera at a web+stellar:pay?destination=…&amount=… code — which is what a payment-request QR actually contains, and what the wallet's own receive screen generates — did nothing at all. Worse, it failed silently: the camera just kept scanning with no feedback. #468 asks for "scanning a Stellar/SEP-7 QR", so this was half the feature.

It now goes through parseQrValue from lib/sep7.ts (added in #518, which handles exactly this bare-address-or-URI branch), falling back to the plain address path.

Validation swapped for the checksum version. The local helper was:

return (v.startsWith('G') || v.startsWith('C')) && v.length === 56;

lib/address.ts landed in #540 with StrKey-backed validation, so a mistyped or corrupted address of the right shape is now rejected instead of being accepted and passed to the send form.

Wired it into the send screen. Nothing rendered QrScanner, so the acceptance criterion couldn't hold. It's now behind a "Scan QR" action beside "Choose contact" on (tabs)/send.tsx, and a successful scan fills the recipient field.

Also dropped the re-added app.json — main uses app.config.ts, which already registers the expo-camera plugin along with its permission string ("Veil uses the camera to scan WalletConnect QR codes"), so the native permission prompt is configured.

Verified: tsc --noEmit clean, jest 12 suites / 206 tests, expo lint clean, CI green.

One follow-up: a SEP-7 code carries amount, asset_code and memo alongside the destination, and parseQrValue already returns them — right now only the destination is used. Passing the rest through to prefill the amount and memo fields would make scanning a payment request genuinely one-tap. Small change, worth its own issue.