test(mobile): add Maestro e2e flows for the critical paths

[Olorunfemi20]

What

Ports the web Playwright scenarios in frontend/wallet/e2e/ to Maestro, so the create-wallet, send, and receive paths are protected by device tests, plus a real-device passkey smoke test.

closes #499

Replaces #510. That branch's net diff is gone — this is a fresh branch off current main, so there is no overlap with the deep-linking work that merged in #508 and nothing to reconcile.

Why the last run failed, and what changed

All four flows failed on the same line, the assertVisible: id: "home-screen" at the end of launch-fresh.yaml, so nothing past the cold start was ever exercised. Two separate causes, both addressed:

1. The flows described an app that no longer exists. home-screen, send-screen, receive-address and the rest were written against the placeholder screens from #508. Since then app/index.tsx became an entry router, /send and /receive moved into (tabs), and #539 replaced the receive placeholder outright. Every selector has been rewritten against the current source, and the missing testIDs are added.

2. The offline gate. Your diagnosis was right. ConnectivityGate pushes /offline whenever NetInfo positively reports no usable connection, and a freshly booted emulator often has not validated its network when the first flow launches. That is handled in two places: the workflow now waits for dumpsys connectivity to report VALIDATED before running Maestro, and subflows/dismiss-offline.yaml retries the probe and falls back to back if it is still up. A slow network now delays a flow instead of failing it, and the fallback means a genuinely offline emulator still runs everything — none of these flows needs the network.

testIDs added

Additive only; no behaviour changes.

File	Added
components/ScreenScaffold.tsx	optional testID prop forwarded to the root view, so any scaffolded screen can be identified
app/(tabs)/dashboard.tsx	dashboard-screen
app/(tabs)/send.tsx	send-screen, send-submit
app/(tabs)/receive.tsx	receive-screen, receive-address, receive-copy-button, receive-share-button
app/(onboarding)/welcome.tsx	welcome-screen, welcome-get-started-button, welcome-recover-button (plus accessibilityRole="button" on both, which they were missing)
app/offline.tsx	offline-screen, offline-retry-button

send-recipient, send-amount and send-memo were already there from your #508 merge and are used as-is. tutorial-overlay / tutorial-skip-button landed with #530, so the guard in skip-tutorial.yaml is now live rather than a no-op — dashboard.yaml is where it actually fires.

Two structural notes

Reaching the tabs takes a deep link. app/index.tsx routes to /dashboard only once a wallet address is in secure storage, and the placeholder create-wallet screen does not persist one (backlog #25). So open-dashboard.yaml opens veil://send to mount the tab navigator and crosses the tab bar from there. It is one subflow, and it is the single place to change when registration starts persisting an address.

One flow asserts an unfinished behaviour on purpose. In create-wallet.yaml, tapping Continue returns to /, and with no wallet persisted the entry router sends you back to create-wallet rather than the dashboard. That is the current correct behaviour, so the flow asserts it — with a comment saying the assertion becomes dashboard-screen once registration writes an address, and that it failing is exactly the signal that the wallet is now being persisted. I would rather encode that than leave a gap.

Layout

.maestro/
  config.yaml              entry points and the default tag filter
  flows/
    create-wallet.yaml     onboarding through to a created wallet
    send.yaml              send form, recipient validation, prefill from a link
    receive.yaml           address, QR, copy and share
    dashboard.yaml         first-run tutorial skip and the quick actions
    deep-link.yaml         cold-start and warm-resume routing for every scheme
    passkey-smoke.yaml     real-device only; tagged `device`
  subflows/
    launch-fresh.yaml      cold start from wiped state
    dismiss-offline.yaml   get past the offline screen
    skip-tutorial.yaml     dismiss the first-run tutorial (backlog #27)
    open-dashboard.yaml    reach the dashboard tab from a wiped install

The pieces you called out as worth keeping are unchanged: flows/*.yaml as the only entry points with subflows/ as fragments, device excluded by default with the documented --include-tags device escape hatch, and clearState: true on every launch.

What the flows assert

send.yaml picks up the validation from #540 — a malformed address raises the error, a valid one clears it, and send-submit only enables once the address parses and the amount is positive. receive.yaml asserts the copy confirmation and a tab round-trip; the share sheet is OS UI, so it asserts the button rather than the dialog. deep-link.yaml covers all three schemes on both launch paths plus the unrecognised-link fallback, which now lands on the welcome screen via the entry router.

Selectors are testIDs. Text assertions are limited to copy that is itself under test (the validation message, the "Copied" confirmation), tab-bar labels, and system UI.

Identifiers

Untouched, per your note — xyz.veil.wallet and app.veil.xyz are used exactly as they are on main. If the canonical values change, appId in the flow headers and the adb install target in the workflow are the only places to update.

Verification

Locally: npm run typecheck clean, npm test green (16 suites, 275 tests), and all twelve YAML files parse.

The emulator run is what this PR needs to prove and it is what the workflow does on this PR. I have no emulator or passkey-enrolled handset here, so I am not claiming a green run I have not seen — if CI is still red I will work it until it is green rather than hand it back to you.

[vercel]

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

A member of the Team first needs to authorize it.