feat: support paykit receiver paths

[ben-kaufman]

This PR:

1. Updates Paykit to v0.1.0-rc33 and configures the mobile app as the bitkit/wallet receiver.
2. Discovers and saves supported bitkit/wallet and bitkit/server receivers while keeping one visible contact per Pubky identity.
3. Scopes private links, payment details, reservations, retries, and cleanup to the exact receiver path.
4. Publishes the wallet receiver marker with the app's current public/private capabilities and removes it when Paykit sharing is disabled.
5. Refreshes receiver discovery when an existing contact is scanned or pasted, while normal send-to-contact continues to target bitkit/wallet explicitly.

Description

Paykit now supports multiple apps under one Pubky identity. This change adopts that model without changing Bitkit's contact UI: a person remains one contact, while their saved SDK contact record can track multiple receiver paths.

Private links are maintained for supported receivers that advertise private capabilities. Receiving details are published independently per receiver and only when that receiver can send payments, so a bitkit/server receiver can be discovered and linked without receiving wallet invoices or addresses. Public contact payments and fallback remain scoped to bitkit/wallet.

Receiver-record failures are isolated per contact, and rescanning an existing contact refreshes only that contact while showing the validation result immediately.

No migration is included because the receiver-path Paykit state has not shipped and existing development state can be discarded.

Companion iOS PR: synonymdev/bitkit-ios#620

Preview

N/A

QA Notes

Manual Tests

• 1. Contacts → add a Paykit-enabled Bitkit user: one contact is saved and its bitkit/wallet receiver is available for payment.
• 2. Send → Contact → select the saved contact: private payment resolves through bitkit/wallet; public fallback still works when private payment is unavailable.
• 3. Existing contact → scan or paste the same Pubky key after a bitkit/server receiver is published: the contact remains one row and the new receiver is saved in the background.
• 4. Contact with a bitkit/server marker that cannot send payments: Bitkit may maintain its private link but does not publish wallet invoices or addresses to that receiver.
• 5. Settings → Payment Preferences → disable contact payment sharing: receiver-scoped payment details and the local receiver marker are cleaned up.

Automated Checks

• PrivatePaykitRepoTest.kt and PublicPaykitRepoTest.kt cover receiver-scoped resolution, publication, cleanup, reservations, and fallback behavior.
• RefreshContactPaykitReceiversUseCaseTest.kt, PrivatePaykitRepoTest.kt, and contact view-model tests cover targeted receiver refresh and per-contact failure isolation.
• Full testDevDebugUnitTest, compileDevDebugKotlin, and detekt passed locally.
• git diff --check passed.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[greptile-apps]

Greptile Summary

This PR adds receiver-path support to Paykit contact payments. The main changes are:

• Paykit is updated to the receiver-path-aware SDK APIs.
• Contacts now store supported bitkit/wallet and bitkit/server receiver paths.
• Private links, invoices, addresses, retries, and cleanup are scoped by receiver path.
• The app publishes or removes the local wallet receiver marker based on sharing settings.
• Contact import and existing-contact refresh flows now refresh receiver discovery.

Confidence Score: 4/5

The receiver-path flow has state cleanup and marker lifecycle bugs that need fixes before merging.

• Turning off public sharing can remove the wallet receiver marker while private sharing is still expected to work.
• A single-contact refresh can leave other saved contacts missing from the in-memory rotation set after restart.
• Receiver cleanup can miss saved paths that are not present in linked-peer state or local published-path cache.

PrivatePaykitRepo.kt and SettingsViewModel.kt

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt	Adds receiver-path scoping for private Paykit publication, retries, invoices, address reservations, and cleanup; several changed state paths can leave contacts or receiver paths out of later cleanup and rotation.
app/src/main/java/to/bitkit/services/PaykitSdkService.kt	Adapts Paykit SDK calls to receiver-path-aware APIs and adds receiver marker publication and discovery helpers.
app/src/main/java/to/bitkit/repositories/PublicPaykitRepo.kt	Scopes public contact resolution to the wallet receiver path and centralizes local receiver marker sync.
app/src/main/java/to/bitkit/viewmodels/SettingsViewModel.kt	Updates sharing cleanup and marker synchronization, with one path that can remove the marker while private sharing should remain discoverable.
app/src/main/java/to/bitkit/usecases/RefreshContactPaykitReceiversUseCase.kt	Adds a targeted receiver refresh use case for rescanning or opening an existing contact.

_{Reviews (1): Last reviewed commit: "fix: harden paykit receiver refresh" | Re-trigger Greptile}

[jvsena42]

@ben-kaufman I'll review today, please solve the conflict

[jvsena42]

Approved with some suggestions

[jvsena42]

[bitkit_e2e.apk Android #0-0] add contact pubky9tm89bfrr3qxic5nbf9oyxfym4cd4jagx68ukogw1j1pz66ksq6y: expected AddContactPay visible (fixture ableToPay=true)

Please, check if this an issue from the PR or the E2E setup

[ben-kaufman]

Already asked @piotr-iohk to help with the e2e tests. Since the way we save data changed we need to updated the existing tests to use this new structure with the pre made users