fix: establish private Paykit links promptly

[ben-kaufman]

Description

• Refresh each saved or scanned contact’s current Paykit receiver paths from Pubky during private sync and persist newly published paths such as bitkit/server.
• Start a bounded 28-second, two-second-cadence private link/message sync burst after contact updates, path discovery, app foregrounding, and network restoration, then return to the existing low-frequency polling cadence.
• Refresh incoming Payment Requests during the same bounded window so a newly linked request opens automatically without waiting for the normal 30-second poll.
• Preserve private-only resolution semantics; no public payment fallback was added.

Preview

No UI changes.

QA Notes

Regression coverage verifies that a contact saved with only bitkit/wallet later discovers bitkit/server, persists it, calls ensureLinkWithPeer, and never starts public payment resolution. Existing send-flow coverage now also verifies that Payment Request polling refreshes immediately when activated.

CI is the authoritative Android build/test run because the native GitHub Packages dependencies require repository package credentials.

[greptile-apps]

Greptile Summary

The PR accelerates discovery and establishment of private Paykit links and refreshes incoming payment requests during the same bounded synchronization window.

• Merges newly discovered supported receiver paths into saved contact records.
• Starts two-second-cadence private-link synchronization bursts after relevant contact, foreground, channel, and connectivity events.
• Adds immediate bounded payment-request polling alongside the existing low-frequency polling cycle.
• Extends regression coverage for delayed receiver-path discovery and immediate request refresh.

Confidence Score: 5/5

The PR appears safe to merge because no blocking failure remains in the eligible follow-up review scope.

No blocking failure remains.

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt	Adds bounded private-link synchronization, receiver-path discovery and persistence, lifecycle cleanup, and burst notifications.
app/src/main/java/to/bitkit/usecases/RefreshContactPaykitReceiversUseCase.kt	Starts the synchronization burst after a successful explicit contact receiver refresh.
app/src/main/java/to/bitkit/viewmodels/AppViewModel.kt	Connects synchronization bursts to lifecycle and connectivity events and adds immediate bounded payment-request polling.
app/src/test/java/to/bitkit/repositories/PrivatePaykitRepoTest.kt	Covers discovery, persistence, and private link establishment for a receiver path published after contact creation.
app/src/test/java/to/bitkit/usecases/RefreshContactPaykitReceiversUseCaseTest.kt	Verifies burst startup occurs only after successful contact receiver refresh.
app/src/test/java/to/bitkit/viewmodels/AppViewModelSendFlowTest.kt	Updates request-polling coverage for immediate and periodic refresh behavior.
changelog.d/next/1141.fixed.md	Documents the reduced delay for private payment requests.

Sequence Diagram

sequenceDiagram
    participant Event as Contact / Foreground / Network Event
    participant VM as AppViewModel
    participant Repo as PrivatePaykitRepo
    participant Pubky as PubkyService
    participant Paykit as Paykit SDK
    participant Requests as PaymentRequestRepo

    Event->>VM: Trigger private synchronization
    VM->>Repo: startInitialLinkBurst(contactKeys)
    loop Every 2 seconds for bounded window
        Repo->>Pubky: discoverRelevantReceiverPaths(contact)
        Pubky-->>Repo: Supported receiver paths
        Repo->>Pubky: Persist newly discovered paths
        Repo->>Paykit: Ensure private links/endpoints
        VM->>Requests: Refresh incoming requests
    end

Loading

_{Reviews (2): Last reviewed commit: "fix: stop retrying removed paykit reques..." | Re-trigger Greptile}

[ovitrif]

Deleting a Paykit contact during an active private-link burst leaves that peer's key in the burst set, which allows later ticks to re-establish private links or republish endpoints for the rest of the 28s window.

[ovitrif]

I see startInitialLinkBurst accumulate with initialLinkBurstPublicKeys += publicKeys and return immediately on an empty normalized batch without cancelling the job or clearing that set. After AppViewModel removes deleted contacts it restarts the burst with the remaining keys (or empty when the last contact is deleted), so previously queued keys stay in the burst for the rest of the ~28s window and keep flowing through refreshSavedContactEndpointsDuringInitialLinkBurst / receiverPathsForSavedContact—including ensureLinkWithPeer and a possible saveContact after removeSavedContact already cleaned them. Could we replace the burst key set on each start and cancel/clear the burst when the provided key batch is empty?