feat: support incoming paykit requests

[ben-kaufman]

Description

This PR builds on #1084 to support incoming Paykit payment requests:

• Updates Paykit to 0.1.0-rc39 and uses its separate public and private payment resolution APIs.
• Receives supported one-time Bitcoin payment requests while Bitkit is active, discarding expired or unsupported requests.
• Reuses the existing send confirmation and payment flow, with a Payment Request title, fixed requested amount, and requesting contact.
• After the user approves, validates that the request remains pending, consumes the private payment list, accepts the request, then submits payment.
• Uses public payment details only when no Noise channel is established and never falls back from private to public resolution.
• Persists consumed private payment-list versions before submission, treats submitted, pending, and uncertain payments as consumed, waits for newer details, and serializes private payments per contact and receiver path.
• Advertises payment-request support with the live Paykit session.

Payment proofs and receipts remain out of scope.

References:

• Base PR: feat: add Paykit server accounts #1084
• Companion iOS PR: feat: support incoming paykit requests bitkit-ios#637

Preview

N/A — the existing payment UI is reused, and no media is attached.

QA Notes

Manual Tests

• 1. Receive a request from a linked Paykit contact while Bitkit is active: the Payment Request confirmation opens with the contact and requested amount.
• 2. Swipe to pay: the request is accepted and payment continues through the existing send flow.
• 3. Receive or retain a request past its expiration: it is discarded and not presented.
• 4. Attempt another private payment before the contact publishes a newer payment list: Bitkit waits and does not reuse the consumed details or fall back to public details.

Automated Checks

• PaykitPaymentRequestRepoTest.kt: request mapping, expiry, lifecycle, and acceptance.
• PrivatePaykitRepoTest.kt: separate resolution, consumed-list persistence, and prevention of private payment-detail reuse.
• AppViewModelSendFlowTest.kt: presentation, polling, approval order, expiry, and duplicate or pending consumption.
• Gradle compilation, affected unit tests, and Detekt passed.

[greptile-apps]

Greptile Summary

This PR adds support for incoming Paykit payment requests. The main changes are:

• Polls for supported requests while the app is active.
• Reuses the send confirmation flow with fixed request details.
• Separates private and public payment resolution.
• Persists consumed private payment-list versions.
• Updates Paykit capabilities, SDK adapters, and related tests.

Confidence Score: 4/5

The legacy backup restore path needs a compatibility fix before merging.

• Backups created by previous releases are raw SDK-state strings.
• The updated restore path requires the new JSON envelope and fails before restoring old data.
• The request lifecycle and private payment flow otherwise have consistent guards and state handling.

app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt	Adds private resolution and consumed-version persistence, but the new backup envelope breaks restoration of legacy backups.
app/src/main/java/to/bitkit/repositories/PaykitPaymentRequestRepo.kt	Adds synchronized request intake, filtering, expiration, and acceptance.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Connects request polling and presentation to the existing payment flow.
app/src/main/java/to/bitkit/services/PaykitSdkService.kt	Adapts the service to separate public and private Paykit APIs and advertises request support.

Sequence Diagram

sequenceDiagram
    participant Contact as Paykit Contact
    participant SDK as Paykit SDK
    participant Requests as Payment Request Repo
    participant App as App View Model
    participant Private as Private Paykit Repo
    participant Wallet as Send Flow

    Contact->>SDK: Publish payment request
    Requests->>SDK: Receive and query requests
    Requests-->>App: Emit actionable request
    App->>Private: Resolve private payment details
    Private->>SDK: Resolve after consumed version
    SDK-->>Private: Endpoint and list version
    Private-->>App: Open payment details
    App-->>Wallet: Show confirmation
    Wallet->>App: User approves
    App->>Requests: Accept request
    App->>Private: Persist consumed version
    App->>Wallet: Submit payment

Loading

_{Reviews (1): Last reviewed commit: "feat: support incoming paykit requests" | Re-trigger Greptile}

[ben-kaufman]

Restacked onto the current #1084 head after its force-push. The request/review-fix commits are signed; the retry fix previously referenced as cf14578b1 is now e01a3ce25, with 44d58d2b8 preserving the Paykit rc39 integration across the rewritten base.

The current build failure is inherited unchanged from #1084: both jobs fail in WatchOnlyAccountStore.kt on unresolved serializedExtendedPubkey references at lines 6 and 29. I left #1084 untouched, as it is being handled separately.

[jvsena42]

Re-reviewed the changes since my last pass. All 8 comments I raised are addressed — resolved those threads. Verified locally on 796bc2b1: the Paykit unit tests (PaykitPaymentRequestRepoTest, PrivatePaykitRepoTest, PublicPaykitRepoTest, AppViewModelSendFlowTest, PaykitSdkServiceTest, ContactPaymentSettingsRepoTest) all pass and detekt is clean.

A few new findings below. Only the first one blocks.

One extra nit that has no diff line to attach to: PrivatePaykitRepoTest.kt:32 — import org.mockito.kotlin.anyOrNull is now unused (base had 4 usages, this branch has 0). detekt reports it as NoUnusedImports, but ignoreFailures = true in app/build.gradle.kts keeps CI green.

[ben-kaufman]

All fresh review findings are addressed in 5866dc2ef, including the no-diff-line anyOrNull import nit. The focused behavior changes have regression coverage, and detekt passes with only the repository's existing unrelated warnings. Local Gradle unit compilation was blocked at dependency resolution because this machine's GitHub Packages token lacks read:packages; the pushed CI run is the compile/test gate.

[jvsena42]

Only one finding worth adressing from last changes

[jvsena42]

utAck, implementation still not end-to-end testable