refactor: batch paykit contact cleanup

[ben-kaufman]

Description

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

• Reads the SDK linked-peer list once per multi-contact publication or cleanup pass, with one shared retry instead of a per-contact fallback.
• 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.
• Serializes cleanup with endpoint publication and skips the local state wipe if relevant contact state changes during an awaited SDK operation.

On the error path, a failed link snapshot still clears locally recorded published receiver paths while retaining the contact state and retry marker. A batch-level drain-inspection failure conservatively keeps the whole affected batch pending for retry. No user-facing behavior changes are intended.

Linked Issues/Tasks

• Base PR: feat: support incoming paykit requests #637
• Review follow-up: feat: support paykit receiver paths #620
• Companion Android PR: refactor: batch paykit contact cleanup bitkit-android#1099

Screenshot / Video

N/A — service-only refactor.

QA Notes

Manual Tests

N/A

Automated Checks

• PrivatePaykitServiceTests.swift: all 13 focused tests passed in the iOS simulator, including mixed cleanup success/failure coverage.
• SwiftFormat passed for the changed Swift files.
• git diff --check passed.

[greptile-apps]

Greptile Summary

This PR batches Paykit contact cleanup work to reduce repeated SDK calls. The main changes are:

• Reads and groups linked peers once per publication or cleanup batch.
• Drains outbound private messages once after clearing the batch.
• Tracks cleanup success and cached-state removal per contact.

Confidence Score: 4/5

The batch-wide linked-peer failure path can leave stale endpoints without a cleanup retry.

• Successful batch processing keeps failures isolated by contact.
• A failed shared lookup suppresses cleanup updates and retry keys for every contact.
• Non-immediate publication callers can discard that failure.

Bitkit/Services/PrivatePaykitService+Contacts.swift

Important Files Changed

Filename	Overview
Bitkit/Services/PrivatePaykitService+Contacts.swift	Batches linked-peer reads and message draining while preserving per-contact cleanup state, but the shared lookup failure path can omit cleanup and retries.

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

[jvsena42]

Reviewed the batching refactor. The per-contact failure isolation contract does hold — I traced the partial-failure cases (one path of two fails, drain still pending, link inspection fails) and each ends with the contact in failedPublicKeys, state untouched, retry marker set. SwiftFormat lint passes and omitting a changelog fragment is correct for a refactor: with no user-facing change.

Comments inline. The one I'd want addressed (or explicitly accepted) before merge is the widened actor-reentrancy window on the deferred state wipe; the rest are smaller.

Test coverage: no test changes here. PrivatePaykitServiceTests.swift has 12 tests, none of which touch removePublishedEndpoints or linkedPeers, so the new batching, the failedPublicKeys/successfulPublicKeys split, and the snapshot-failure fallback are all untested. The "all 10 focused tests passed" note in the description is a regression run, not coverage of this change. Given the state-clearing logic is the risky part, a test asserting "contact A succeeds, contact B fails → A cleared + marker cleared, B state retained + marker set" would be worth adding.

Merge order: base is codex/paykit-incoming-payment-requests, so this needs to land behind #637.