feat: send paykit payment proofs

[ben-kaufman]

This PR sends a Paykit payment proof back to the requester after Bitkit successfully pays an incoming private payment request.

Description

1. Persists the payer identity, request, and selected endpoint before request acceptance, then associates the Lightning payment hash before sending so restart recovery keeps the correct correlation.
2. Persists successful on-chain transaction IDs and validated Lightning preimages before submitting them against the original one-time request and exact endpoint.
3. Uses Paykit's durable private outbox, retries incomplete submissions during normal request refresh, and suppresses duplicate proofs already recorded by the SDK.
4. Preserves earlier in-flight correlations across retries, clears the request after one proof is queued, and reads the secure store directly so wallet wipes cannot resurrect cached proof state.
5. Attempts immediate SDK delivery if persisting a completed proof fails, without adding any user-facing UI.

This PR is stacked on #676. Companion Android PR: synonymdev/bitkit-android#1178

Linked Issues/Tasks

N/A

Screenshot / Video

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. iOS → create a private request for Android → Android receives and pays on regtest: iOS records the proof against the exact request, endpoint, and transaction ID.
• 2. Android → create a private request for iOS → iOS receives and pays on regtest: Android records the proof against the exact request, endpoint, and transaction ID.

Automated Checks

• PaykitPaymentProofServiceTests.swift: 8 tests cover restart retry, duplicate suppression, invalid Lightning preimage rejection, failed-payment cleanup, exact on-chain proof submission, overlapping retries, wallet-store clearing, and completed-proof persistence failure.
• Focused iOS proof tests passed: 8 tests, 0 failures.
• Final iOS simulator Debug test build passed.
• SwiftFormat and git diff --check passed.

[ovitrif]

On-chain payment proofs cannot recover after a store-load failure, so a successful send can still leave the requester without proof.

[ovitrif]

QA Notes

Ran on iPhone 17 Pro simulator and Pixel_9a emulator on regtest.

• iOS created a private request for Android, Android paid, and iOS recorded the proof against that request.
• Android created a private request for iOS, iOS paid, and Android recorded the proof against that request.

Approve.

[ben-kaufman]

Added the cross-platform proof-state hardening in c3f2d8c: corrupt persisted proof state is discarded instead of permanently blocking reconciliation, empty state removes the Keychain entry, and the frequent refresh path returns before calling Paykit when there is nothing to reconcile. The full payment-proof suite passes 22/22 on the restacked subscriptions head.

[ben-kaufman]

Follow-up after the final cleanup: the hardening commit is now 281b8654 (signed). I removed the unnecessary decoder-only test hook while keeping the meaningful regression that proves empty reconciliation skips the Paykit SDK. PaykitPaymentProofServiceTests: 21/21 passing.

[ben-kaufman]

CI note: the remaining pubky_paykit red check is test-harness instability rather than a proof-code failure. Its three internal attempts failed at Appium session creation, waiting for the generic send slider, and teardown/profile cleanup respectively; the final attempt had already dragged the send slider successfully. The same Paykit staging scenario passes on stacked PR #685 with this exact proof implementation. GitHub currently refuses an isolated rerun because this workflow’s unrelated local E2E job is still queued; I will rerun the failed job once the workflow finishes.

[ovitrif]

utACK