feat: open pubky auth links

[ovitrif]

Closes #715

This PR lets iOS receive uniquely targetable Pubky marketplace setup links and route them into the existing explicit watch-only account consent flow.

Description

• Accept bitkit://pubky-auth/setup?<original query> through Bitkit's existing iOS URL scheme without competing with Pubky Ring for pubkyauth.
• Require exactly one supported Bitkit claim marker on every Bitkit-specific wrapper and reject fragments or malformed query delimiters.
• Preserve raw pubkyauth requests for QR scanning and clipboard paste.
• Retain external URLs above startup, restoration, and PIN gates, then consume them when the main wallet UI is available.
• Keep valid setup requests on the existing watch-only consent path.
• Keep Pubky Ring detection and outbound authorization deterministic through Ring's pubkyring scheme.
• Expose malformed or unsupported request failures through an accessibility identifier without authorizing or exporting account material.
• Add focused bundle/retention coverage and a cold-start external-app handoff journey.

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-owned 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 onboarded wallet with Paykit UI and a local Pubky identity → open a valid watch-only bitkit://pubky-auth/setup link from a browser or external app, then finish startup/unlock: watch-only consent opens with Cancel and Approve actions.
• 2. Watch-only consent → Cancel: returns without authorizing or exporting account material.
• 3. Open a bitkit://pubky-auth/setup link with an unsupported Bitkit claim: invalid-request toast appears and watch-only consent stays closed.
• 4. regression: Scanner → Paste QR Code with the valid setup link: watch-only consent opens.
• 5. regression: Scanner → scan or select a QR image containing the valid setup link: watch-only consent opens.

Automated Checks

• Focused XcodeBuildMCP simulator tests: 48 passed, 0 failed, 0 skipped (PubkyAuthURLSchemeTests, PubkyAuthRequestTests, PubkyRingDeepLinkTests, PubkyAuthPermissionTests).
• XcodeBuildMCP Debug simulator build: passed.
• XcodeBuildMCP E2E Debug simulator build and build-and-run: passed.
• SwiftFormat lint: passed for all changed Swift sources; the base MainNavView one-line if-expression rule was excluded.
• Translation validation: 0 errors.
• Info.plist, journey XML, and diff validation: passed.
• Startup/restoration/PIN regression coverage retains the URL, routes through the production scanner-to-sheet path after readiness, and verifies one consent presentation.
• Wrapper provenance coverage rejects marker-less generic capabilities through the production scanner-to-sheet path; encoded %23 remains data while literal fragments are rejected.
• Earlier scanner paste regression evidence reached PubkyAuthWatchOnlyConsent; raw protocol scanning remains supported.
• QR photo selection reached Bitkit, but iOS 26.5 Simulator Vision stopped before decoding with com.apple.Vision Code=9 (Could not create inference context); device scan remains manual test 5.
• Exact-head GitHub CI passed: translations, unit tests, integration tests, Pubky/Paykit E2E, local E2E, and the rerun of the unrelated flaky multi-address E2E shard.

Coordination

• The owning Bitkit issue records the external marketplace producer dependency and owner handoff; the generic Pubky App xpub signer flow remains unwrapped.
• Independent full review is clean for receiver head d8110c042cb4c9002e7fecda9beb8d2a8cd87d67.

[ben-kaufman]

This catch-all still keeps bitkit://gift-<code>-<amount> links pending until LDK is running. BitkitCore decodes that registered deep-link format into .gift, and GiftLoading already waits for the node and shows its failure UI. On an offline launch or node-start error, the new path gives no gift sheet or error and may delay a limited gift claim indefinitely. Could we release the Bitkit gift namespace after the startup/PIN gates and add an offline routing case?