mobile: implement onboarding create flow (backlog #25)

[popdadyrisky]

Implement mobile onboarding create flow that:
Registers a WebAuthn passkey via the Invisible Wallet SDK
Derives a deterministic fee-payer Keypair from the passkey credential ID (HKDF → Ed25519)
Funds the fee-payer via Friendbot (testnet) or verifies mainnet funding
Deploys the wallet contract through the factory using wallet.deploy()
Writes session state (invisible_wallet_address, veil_signer_secret) to sessionStorage and navigates to /dashboard
Files:
frontend/mobile/app/(onboarding)/create.tsx
Acceptance:
WebAuthn credential created → wallet contract deployed → session set → dashboard landing (see QA steps)
Notes:
The mobile flow keeps the signer secret ephemeral until after deploy (opt-in reveal). Web onboarding persists the secret prior to deploy; consider aligning behavior if desired.

closes #453

[vercel]

@popdadyrisky 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]

@popdadyrisky 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! One thing to reconcile before this lands: main already has a create-wallet flow at frontend/mobile/app/create-wallet.tsx, and this adds a separate app/(onboarding)/create.tsx — so the app would have two create screens on different routes. Could you rebase onto main and either fold this into the existing create-wallet.tsx or clearly replace it (and update the navigation), rather than adding a parallel route? Then I'll re-review.

[Miracle656]

Thanks @popdadyrisky — nice onboarding UX. Blocker: this is written for the web runtime and won't run on React Native as-is — it uses next/navigation, localStorage, window/document, and qrcode.react (a react-dom library), none of which exist on native. It also uses deriveFeePayerKeypair, which ADR 0003 deprecated (C2/C3 — deriving the fee-payer from the credential ID).

#594 just landed the correct native pattern — please rebuild on top of it:

• expo-router for navigation (not next/navigation)
• expo-secure-store / AsyncStorage for storage (not localStorage)
• react-native-passkeys for registration
• react-native-qrcode-svg for the QR
• the SDK's PRF-based fee-payer, not deriveFeePayerKeypair

Happy to help scope it.

[Miracle656]

Apologies for the month this waited — that is on us.

Reviewed it against current main, and there is one thing to resolve before it can land.

Nothing routes to this screen. The onboarding folder currently holds only _layout.tsx and welcome.tsx, and welcome's create button goes elsewhere:

// app/(onboarding)/welcome.tsx:51
const handleCreate = async () => {
  await AsyncStorage.setItem(SEEN_WELCOME_KEY, '1');
  router.push('/create-wallet');
};

app/create-wallet.tsx exists and is ~10.5KB of working create flow. So as it stands, adding (onboarding)/create.tsx gives us a second create screen that no path reaches — 439 lines of dead code, and two implementations of the same flow to keep in step.

Which is the intent?

1. Replace — this supersedes create-wallet.tsx. Then the PR should also repoint handleCreate to /create and delete the old screen, so there is exactly one create flow.
2. Complement — it does something create-wallet.tsx does not. Then say what, in the PR description, and wire the route that reaches it.

Either is fine; what cannot land is a screen with no way in. We have had that pattern bite twice recently — most recently a hook that was added but never mounted, so the feature it described never ran.

If you would rather not carry this forward after the delay, that is completely fair. Not closing it either way. If option 1 is the intent and you want me to check the two screens against each other and tell you what create-wallet.tsx has that this does not, say so and I will.