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

[jvsena42]

Found some points that worth a double check

[ben-kaufman]

@jvsena42 Fixed in e66771b. The Payment Request card now uses the shared expanded CustomButton layout in this PR, so the Figma button sizing fix is no longer deferred to #685. The proof delivery comments are also addressed in this head and replied to inline.

[ben-kaufman]

The requested proof lifecycle and Payment Request button fixes are now on the signed e66771b head, all inline threads are resolved, and the focused proof tests pass. @jvsena42 and @ovitrif please re-review when the current E2E run finishes.

[piotr-iohk]

Retested latest revision, iPhone 17 sim ↔ Pixel emu (same session as android #1178).

Amount edit on pay (iOS only)
Paying an incoming request opens the amount pad on iOS. Android goes straight to Confirm and the amount is locked. I changed 1000 → 1009 and swipe failed with Payment failed: amountMismatch (SendConfirmationView.performPayment). Confirm already blocks the amount tap when incomingPaymentRequest is set; looks like the first route still lands on .amount when the opened LN invoice amount is 0.

Recording:

Screen.Recording.2026-09-01.at.16.08.22.mov

Request lists don’t match
Same session, both on TODAY:

• iOS: 3× 1000 + 26 000 (no 25 000)
• Android: 2× 1000 + 26 000 + 25 000

Not amount-keyed overwrite in the app list — IDs are paymentRequestId + counterparty + path. The 25k did land: Android sent it on-chain, iOS activity shows +25 000 (81eaa51b…). It’s missing as an iOS request-history row. Extra 1k on iOS / missing 1k on Android looks like the same thing. Hypothesis: after fulfill, one side drops the row when localRole is missing/unknown (history mapping skips those). Avatars A vs I are just the contact names.

Screenshot (Payment Requests list):

Logs:
bitkit_logs_2026-09-01_14-14-42.zip

Proofs still queued on the successful pays (LN + on-chain both ways). Amount pad / list drift look like follow-ups, not a proofs blocker.

[ben-kaufman]

Thanks — I reproduced the amountless-endpoint route issue and fixed it in signed commit 6bcff553. Incoming Paykit requests now bypass the editable amount routes for both amountless Lightning and on-chain targets and open the existing confirmation screen directly; the amount remains locked there. Focused regression coverage for both target types passes.

I also reran a clean iOS ↔ Android session with two successful requests in each direction. Both apps ended with the same four history rows, and each remote request transitioned to paid after the payer logged the proof as queued. In this path, “queued” means durably accepted by the SDK outbox for delivery, not stuck. I could not reproduce the history divergence or an undelivered proof on the clean current heads, so I have not added a speculative mapping change. Please retest the current head once the fresh checks finish.

[ovitrif]

The Payment Request dismiss control still ignores shouldExpand, so the card actions are not equal-width.

Hardware-funded incoming on-chain pays still skip proof prepare and complete, so those broadcasts never send a proof.

[ben-kaufman]

Fixed both points in signed commit 489b1e61.

• The shared secondary-button renderer now honors shouldExpand, so the Payment Request Dismiss and Pay controls use the same equal-width shared layout. I also removed the redundant per-card width wrappers.
• Hardware-funded incoming on-chain payments now prepare the proof before private-list consumption/broadcast and complete it with the returned txid after a successful broadcast. Known/pre-broadcast failures clean up the preparation; uncertain/connectivity broadcast outcomes retain it for retry, with no second endpoint/list consumption.

Focused simulator verification passes: HwFundingSignerTests 22/22 and PaykitPaymentProofServiceTests 12/12. The hardware retry regression also verifies proof completion fires exactly once and only after the successful broadcast.

[ovitrif]

utACK