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]

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.