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.
• Accepts a request only after the user approves it, before submitting the 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}

[greptile-apps]

Legacy Backups Cannot Restore

Previous releases stored exportBackupState() as a raw string, but this line now decodes every non-null backup as PrivatePaykitBackup JSON. Restoring a backup created before this change therefore fails during decoding and never calls restoreBackupState(); the restore path needs to recognize and migrate the legacy format.

[ben-kaufman]

No code change here: this raw backup format only exists in the unshipped parent Paykit work, so there are no production backups to migrate. Per the pre-release scope of this stack, we are intentionally not adding migration or backward-compatibility code.