feat: open pubky auth links

[ovitrif]

Closes #715

This PR receives Bitkit-targeted Pubky marketplace setup links and keeps them available through startup, restoration, PIN, scene, and app lifecycle delivery until existing watch-only consent can present.

Description

• Accepts only the uniquely targetable bitkit://pubky-auth/setup wrapper with one supported Bitkit claim.
• Routes setup requests, callbacks, BIP21, BOLT11, and gift links after startup gates without waiting for LDK when their destination UI owns readiness and failure handling.
• Displays the parsed authorization relay origin on watch-only consent and authorization without representing it as a verified service identity.
• Rejects malformed, duplicate, unsupported, and unclaimed requests before account material is authorized or exported.

Linked Issues/Tasks

• feat: open Pubky auth links from iOS #715
• Parent: epic: Pubky marketplace wallet support #712
• Android counterpart: test: prove the android pubky marketplace wallet leg bitkit-android#1212
• Paykit trust-boundary handoff: chore: decide linked-peer Payment Request intake policy pubky/paykit-rs#148

Preview

QA Notes

Manual Tests

• 1. Terminated or PIN-locked wallet with Paykit UI and a Bitkit-generated Pubky identity → open a valid setup link → finish startup/unlock: watch-only consent shows the authorization relay origin.
• 2. Watch-only consent → Cancel: returns without authorizing or exporting account material.
• 3. Offline wallet → open bitkit://gift-…: Gift Loading opens and owns node failure presentation.

Automated Checks

• Focused simulator tests: 70 passed across SceneDelegateTests, PubkyAuthURLSchemeTests, PubkyAuthRequestTests, and PubkyAuthApprovalSheetTests on 42affaee.
• E2E Debug simulator build: passed on 42affaee.
• SwiftFormat, translation validation, and git diff --check: passed.
• GitHub Actions: current-head checks are running.

[jvsena42]

Reviewed the link as an attacker-controlled trust boundary. Validation is strict — exact scheme/host/path, no userinfo/port/fragment, exactly one x-bitkit-claim=watch-only-account-v1, caps must equal the fixed watch-only set, duplicate relay/secret rejected — and I could not escalate through it. The wrapper forces requiresBitkitClaim, so ordinaryApproval (the only path that forwards URL-supplied capabilities) is unreachable from a link; the companion path passes the hardcoded watchOnlyAccountCapabilities constant. The claim payload is version|accountIndex|addressType|78-byte xpub — public material, no spending key. Secrets are not logged, and retained-link handling is single-slot and PIN-gated.

One medium, about provenance rather than authorisation. One thing I could not settle offline: whether Pubky Ring actually registers pubkyring:// — if not, Ring sign-in reports "not installed".

Minor gap while you are here: duplicate caps parameters are not rejected the way duplicate relay/secret are. Not exploitable (the companion path never reads URL caps, so a divergence yields rejection), but inconsistent with the other duplicate checks.