Taken over and re-ported onto main. Since the original commits, main rewrote the passkey system (the app's own PRF provider was replaced by the SDK's PasskeyClient register/signIn/labels API), so a literal rebase was not viable. This is a semantic re-port: the intent of the original four commits is preserved and re-expressed against the new API (the migration modal was carried over verbatim and only its API call sites were rewired). The original branch history is preserved in this PR's force-push timeline.

Problem

Production was deployed without VITE_PASSKEY_RP_ID set, so all existing passkeys were created with window.location.hostname as their RP ID. The intended RP ID is keys.breez.technology (a Related Origin Requests / ROR server).

WebAuthn cryptographically binds a passkey to its RP ID at creation time, and since the passkey PRF output IS the wallet seed, a different RP ID derives a completely different wallet. There is no in-place key migration: enabling ROR would orphan every existing wallet.

🔑 @dangeross: BEFORE MERGING, set VITE_PASSKEY_RP_ID to keys.breez.technology.

Solution

Dual RP ID handling (commit "Legacy RP ID handling")

• LEGACY_RP_ID (window.location.hostname on web) for all existing passkeys; ROR_RP_ID (VITE_PASSKEY_RP_ID) for new ones when ROR is configured.
• passkeyRpId persisted in localStorage as device metadata (survives logout, not cleared by clearPasskeyMode).
• Existing users derive under their stored-or-legacy RP ID on resume / label switch, with backfill on first success, so enabling ROR never orphans a pre-migration wallet.
• Because main funnels every passkey op through one module-level rpId, this adds rpId-scoped client construction (buildMigrationPasskeyClient plus a web-only rpId override on signInPinnedToActiveCredential) to replace the deleted mutable passkeyPrfProvider.setRpId().
• Dev-only RP-ID switch in the Passkey settings hub (shown only when ROR differs from legacy).

In-app migration (commit "Passkey migration")

• A PasskeyMigrationModal upgrades a legacy-RP user to the ROR RP ID without losing funds: it creates the ROR passkey once, then per label sweeps the full sats + token balance, the Lightning address, and contacts from the old wallet to the new one, ordering the active label last so its wallet becomes the adopted session.
• Two entry points: an auto-opened banner after a legacy-RP reconnect, and a login-path offer from PasskeyPage when no ROR credential is found. Both are web-gated (the modal uses the browser passkey client; native keeps its fixed RP ID).
• The new ROR credential is recorded as active only on successful switch, so a mid-migration failure never points resume at an unusable credential. Unclaimed deposits across any label block migration until claimed.

Atomic Lightning Address transfer (commit "Atomic Lightning Address transfer")

• The migration's Lightning-address step now uses the SDK's atomic, symmetric two-signature transfer (spark-sdk #829): old.authorizeLightningAddressTransfer({ transfereePubkey }) then newSdk.claimLightningAddressTransfer({ authorization, description }).
• This replaces the prior delete-then-register step, which had a window where the username was unregistered and could be lost. The SDK rejects a self-transfer, already guarded by the in-flow identity assertion.

Review fixes (commit "Fix login-entry passkey migration ...")

A multi-agent adversarial review found the fund-moving, credential-derivation, and state-machine logic clean, and caught two login-path regressions from adapting to main's refactored PasskeyPage, both fixed here:

• Migration is offered on any web detect failure (web has no deterministic no-credential signal, so the previous gate left fresh-browser legacy users unable to migrate).
• Cancelling a login-entry migration navigates home instead of stranding the page on an indefinite "Detecting passkey..." spinner.

⚠️ Merge blocker: SDK

Bumps the vendored SDK to 0.16.1-dev1, built locally from spark-sdk main (commit e4d5f80, which contains #829). The only app-visible WASM API delta versus the prior 0.16.0-dev3 is the two transfer methods plus their request/response types, so the bump is additive and drop-in. Before merge, this needs the SDK officially released with #829 and package.json pointed at the released version.

Known limitations

• Not yet end-to-end tested with live WebAuthn on a ROR-enabled deployment (needs a funded legacy-RP wallet). Verified via type-check, build, browser boot, and the adversarial review.
• If a post-migration user fully wipes localStorage, detection defaults to the legacy RP ID and will not find their ROR passkey; they would use the dev RP-ID switch to recover. Accepted as a rare edge case.