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.