refactor: batch paykit contact cleanup

[ben-kaufman]

Description

This PR builds on #1098 to address the Paykit cleanup performance follow-ups from iOS #620:

• Reads the SDK linked-peer list once per multi-contact publication or cleanup pass instead of once per contact.
• Clears receiver-scoped payment lists as before, then drains outbound private messages and checks pending status once for the whole successful batch.
• Preserves per-contact failure isolation: contacts with failed or still-pending cleanup retain their cached state and retry marker, while successful contacts are cleared.
• Adds regression coverage for one linked-peer snapshot, one batched drain, and partial cleanup failure.

No user-facing behavior changes are intended.

Preview

N/A — repository-only refactor.

QA Notes

Manual Tests

N/A

Automated Checks

• PrivatePaykitRepoTest.kt: all 37 focused tests passed, including the three new batching and failure-isolation tests.
• ./gradlew compileDevDebugKotlin passed.
• ./gradlew testDevDebugUnitTest passed.
• ./gradlew detekt passed with only pre-existing findings outside this change.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR batches private Paykit contact publication and cleanup work. The main changes are:

• Reads linked peers once per multi-contact pass.
• Clears payment lists before one shared message drain.
• Preserves cached state for contacts with reported cleanup failures.
• Adds tests for batching and partial failure handling.

Confidence Score: 4/5

The batched cleanup path can skip remote cleanup or block unrelated contacts, so these cases should be fixed before merging.

• Invalid keys can be treated as successfully cleaned and lose their retry marker.
• One linked-peer lookup failure now prevents cleanup for the whole batch.
• A peer change during the pass can leave remote state without matching cached cleanup state.

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

Important Files Changed

Filename	Overview
app/src/main/java/to/bitkit/repositories/PrivatePaykitRepo.kt	Adds shared linked-peer snapshots, batched cleanup and draining, and per-contact cache reconciliation.
app/src/test/java/to/bitkit/repositories/PrivatePaykitRepoTest.kt	Adds valid tests for one linked-peer read, one shared drain, and partial cleanup failure.

_{Reviews (1): Last reviewed commit: "refactor: batch paykit contact cleanup" | Re-trigger Greptile}

[greptile-apps]

Invalid Key Reports Cleanup Success

When a pending deleted-contact key cannot be normalized, mapNotNull drops it and the empty batch returns success. retryPendingDeletedContactEndpointRemoval then removes the cached contact and retry marker even though its remote payment lists were never cleared, so that cleanup is not attempted again.

[ben-kaufman]

Fixed in e56f9dc. Invalid keys now return InvalidPublicKey instead of being dropped from an empty batch, so the retry marker and cached state are preserved for another cleanup attempt. Added a regression test for this case.

[greptile-apps]

Shared Snapshot Breaks Failure Isolation

When this linkedPeers() call throws, the batch exits before clearing any contact. The previous no-argument flow caught each contact's failure and continued with later contacts, so one transient SDK failure now blocks cleanup progress for every contact in the pass.

[ben-kaufman]

Fixed in e56f9dc. The shared snapshot remains the fast path, but if it fails we retry peer inspection per contact. One contact's failure no longer blocks later contacts, and its locally cached published paths are still cleared while its state remains pending. Added regression coverage for the partial-failure case.

[greptile-apps]

Snapshot Misses Newly Linked Paths

If a receiver path becomes linked after this batch-wide snapshot but before its contact is processed, that path is omitted from receiverPathsForCleanup. The contact can still be marked successful and lose its cache and retry marker while the remote payment list on the missed path remains published.

[ben-kaufman]

I don't think this can leave an untracked payment list. Cleanup unions the snapshot with publishedPrivatePaymentReceiverPaths; queued publications are recorded in that local cache before delivery, and publication/cleanup run on the serialized dispatcher. A path becoming linked by itself does not publish a payment list, so any newly linked path with a list to clear is already covered by the cached published path.

[greptile-apps]

You're right. The two invariants together close the gap I was concerned about:

1. receiverPathsForCleanup unions the linked-peer snapshot with publishedPrivatePaymentReceiverPaths — the local cache independently covers every path that was ever published.
2. The local cache is written before delivery, and publication and cleanup are both serialized on serializedDispatcher, preventing any interleaving that could leave an untracked path.

A newly linked path without a prior publication has nothing in the remote list to clear, so missing it from the snapshot is harmless. My original comment was incorrect — sorry for the noise.