fix: prepare Paykit local auth and private links

[ben-kaufman]

Description

• require Paykit Server watch-only authorization requests to include both public and private server capabilities, independent of capability ordering
• update to Paykit 0.1.0-rc43 and use one cached Pubky client configuration for session bootstrap and the Paykit SDK
• route local E2E Electrum, Homegate, and Pubky/Paykit through one documented E2E_LOCAL_HOST setting while keeping production defaults unchanged
• refresh saved contacts from Pubky so receiver paths published after contact creation, including bitkit/server, are discovered and persisted
• run a bounded two-second private link/message and Payment Request polling burst after contact discovery, foregrounding, and network restoration, then return to the existing low-frequency cadence
• preserve private-only payment resolution with no public-payment fallback

Linked Issues/Tasks

• Local test environment fixes: fix: support Bitkit local wallet tests pubky/locks#11
• Paykit SDK local-testnet configuration and rc43 release: feat: expose local Pubky testnet config pubky/paykit-rs#130
• Matching Paykit Server retry behavior: fix: emit canonical Paykit requests and retry initial links pubky/paykit-server#2
• Matching Android behavior: fix: establish private Paykit links promptly bitkit-android#1141

Validation

• Paykit 0.1.0-rc43 resolves from its published tag and the app builds against its published XCFramework
• PaykitSdkClientConfigTests and PrivatePaykitServiceTests: 16/16 passed after rebasing onto current master
• SwiftFormat and whitespace checks passed
• Clean Locks → Paykit Server → Bitkit proof is being rerun for both platforms

Screenshot / Video

N/A — no new UI; this changes local E2E configuration and private-link synchronization.

[greptile-apps]

Greptile Summary

The PR updates Paykit integration and local E2E configuration while improving private-link and payment-request synchronization.

• Requires both public and private watch-only authorization capabilities regardless of ordering.
• Uses a shared Pubky client configuration for Paykit session bootstrap and SDK operations.
• Adds one local E2E host setting for Homegate, Electrum, and Pubky/Paykit.
• Refreshes saved contact receiver paths and performs bounded initial synchronization bursts.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
Bitkit/Info.plist	Adds build-setting-backed local Homegate and shared local-host values; the verified processed plist behavior preserves the intended fallback.
Bitkit/Constants/Env.swift	Routes local E2E Homegate, Electrum, and Pubky/Paykit endpoints through the shared host while retaining production defaults.
Bitkit/Services/PrivatePaykitService+Contacts.swift	Adds bounded endpoint-refresh bursts and persists newly discovered supported receiver paths.
Bitkit/AppScene.swift	Triggers bounded private-link and payment-request refreshes after contact, lifecycle, and connectivity events.
Bitkit/Models/PubkyAuthRequest.swift	Requires the exact public and private watch-only capability set without depending on capability ordering.
Bitkit/Services/PubkyService.swift	Shares one environment-aware Pubky client configuration between bootstrap and the Paykit SDK.

Sequence Diagram

sequenceDiagram
    participant App as AppScene
    participant Private as PrivatePaykitService
    participant Pubky as PubkyService
    participant Paykit as Paykit SDK
    App->>Private: Start initial link burst
    loop Every 2 seconds, bounded
        Private->>Paykit: Load saved contact record
        Private->>Pubky: Discover receiver paths
        Pubky-->>Private: Current public/private paths
        Private->>Paykit: Persist newly discovered paths
        App->>Paykit: Refresh incoming payment requests
    end

Loading

_{Reviews (3): Last reviewed commit: "test: clarify Paykit burst coverage" | Re-trigger Greptile}

[ovitrif]

Requesting changes for two issues after this watch-only capability change:

• PubkyAuthApprovalSheetTests still build public-only watch-only auth URLs, so PubkyAuthRequest.parse throws before the consent and approval assertions run.
• Docs/watch-only-account-claim-v1.md is incorrect because it still documents only the public server capability as the exact watch-only requirement.

[ovitrif]

Docs/watch-only-account-claim-v1.md still documents only /pub/paykit/v0/bitkit/server/:rw as the exact watch-only capability, which is incorrect after this change requires both public and private server capabilities. That stale contract can leave Android or Paykit Server implementers issuing public-only auth URLs that Bitkit now rejects. Could we update the Request section so it requires both capabilities?

[ben-kaufman]

Addressed the remaining review feedback in 3086813: the watch-only contract now documents both required Paykit Server capabilities, all stale approval-sheet fixtures use the shared production capability constant, and capability matching handles reordered or whitespace-separated entries while rejecting empty entries. The focused request and approval-sheet suites pass all 50 tests on Paykit rc43.

[ovitrif]

Looks good. The previously missing private Paykit Server capability is now required in the approval-sheet fixtures and watch-only claim contract.

[jvsena42]

Starting review

[jvsena42]

No issues found,, only some missing cleanup ports from Android

[jvsena42]

LGTM, waiting for CI to pass before approving