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 #1172. Companion iOS PR: synonymdev/bitkit-ios#683

Preview

N/A — there are no UI changes.

QA Notes

Manual Tests

• 1. 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.
• 2. 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.

Automated Checks

• PaykitPaymentProofRepoTest.kt: 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.
• AppViewModelSendFlowTest.kt: covers proof persistence before private-list consumption and request acceptance, plus successful and failed payment lifecycle handling.
• Full Android unit tests and focused proof/send-flow tests passed.
• Detekt passed with only pre-existing unrelated findings.
• git diff --check passed.

[ovitrif]

Two Lightning test gaps are missing:

• Crash recovery after an associated hash never exercises the LDK lookup, so a broken preimage path would not fail.
• Incoming-request send never asserts prepare, associate, pending keep, or fail-plus-cancel, so a skipped hash association would not fail.

[ovitrif]

Looks good: associated-hash Lightning crash recovery now submits from an LDK succeeded payment, and incoming-request send keeps or clears the proof correlation as required.

[piotr-iohk]

Will test after conflicts are resolved.

The base branch was changed.

[jvsena42]

@ben-kaufman conflicts

[jvsena42]

Can't pay, swipe is disabled

swipe-disabled.webm

[jvsena42]

Root cause and logs for the disabled swipe in the review above.

Why it's disabled

SendConfirmScreen.kt:400 gates the control on:

enabled = uiState.isAmountInputValid && !uiState.isFundingSourceLoading && !isHardwareFeeLoading

isAmountInputValid defaults to false (AppViewModel.kt:4796), and the incoming-payment-request branch navigates to the confirm sheet without ever setting it (AppViewModel.kt:2798):

navigateToSendRoute(fromMainScanner, SendRoute.Confirm, SendEffect.NavigateToConfirm)
refreshOnchainSendIfNeeded()
estimateLightningRoutingFeesIfNeeded()
return

The sibling branch eight lines below (lnAmountSats > 0u, AppViewModel.kt:2806) does set it before its identical navigateToSendRoute call.

Confirmed on device

Two emulators on this branch build, each with its own pubky identity on the staging homeserver, added as contacts; B requested 16 000 sats from A.

• The sheet opens with the swiper dimmed, and injected drags do not move the thumb at all.
• One tap on the funding-source button — selectHardwareFundingSource and the savings branch both assign isAmountInputValid — flips it to full brightness, and the identical drag pays immediately.

Worth flagging that the funding-source toggle is only a workaround because that wallet had a paired Trezor. canSwitchFundingSource = availableFundingSources(state).size > 1 (AppViewModel.kt:2162), so with a single funding source there is no way to pay the request at all: the only control on the screen is dead.

Looks like a one-liner — assign isAmountInputValid = validateAmount(amount) in that branch before navigating, matching :2806.

The proof pipeline itself works once past this

Same run, payer side:

17:30:17.844 INFO [Keychain.kt:144]               Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:27.162 INFO [Keychain.kt:144]               Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'
17:30:28.764 INFO [PaykitPaymentProofRepo.kt:270] Queued a Paykit payment proof for private delivery
17:30:32.407 INFO [Keychain.kt:144]               Upserted value for key 'PAYKIT_PENDING_PAYMENT_PROOFS'

That is prepare() writing the pending record, completeOnchainPayment() filling in txid + proofData, submitReady() queueing delivery, then cleanup. Receiver side picked it up over the encrypted link:

paykit_lib::encrypted_link::link: receive_private_application_messages;
paykit_lib::encrypted_link::link: restore_encrypted_link; remote_pubkey=PublicKey("pubkyej5obc…") local_receiver_path=PaykitReceiverPath("bitkit/wallet") remote_receiver_path=PaykitReceiverPath("bitkit/wallet")

and the request moved from "Waiting for … to pay" into the settled group. A force-stop and relaunch of the payer produced no re-submission and no leftover pending record, and there were no Paykit warnings or errors on either device.

[ben-kaufman]

Fixed the disabled incoming-request swipe in 6d66ab6. The request branch validated the amount but did not persist that result, so Send Confirm kept the swipe disabled. It now writes the validation result before navigation, and the existing incoming payment request opens the existing confirm flow with its fixed amount test asserts that isAmountInputValid is true. The focused test and full unit suite pass.

[ben-kaufman]

The conflicts are resolved and the branch is current. It also now includes the proof-store/polling hardening and the disabled-swipe fix reported in the latest review. Please retest at 6d66ab6.

[ovitrif]

utACK