bug: allowance requests can stay hidden or present manually around an allowance update #1659

Refs:

• feat: add allowances for automatic paykit payments #1340
• feat: accept allowance offers automatically on the allowee's wallet bitkit-ios#841 (review)

What happened?

Follow-ups for automatic allowance payments, found while matching fixes from the iOS twin synonymdev/bitkit-ios#799 after #1340 was frozen for merge:

1. mayCover counts allowances in any state. iOS limits it to proposed or active ones.
2. A request held while allowances update waits for the next poll (up to 10 s) after the update ends. iOS re-runs presentation when the update finishes, so Pay doesn't spin.
3. Restart recovery reads the journal once per attempt; iOS reads it once per pass.

From the review of #1340 at 480ae3a (#1340 (review)), none blocking:

4. A tapped request can stay hidden. The coverage hold in refreshIncomingPaykitPaymentRequests now spans the network intake, and isAllowancePending holds any request whose contact has an allowance in any state. A request the user taps (for example after Limit Reached) is filtered out of presentation with no retry, and after a failed refresh presentation never runs, so nothing opens. Presenting after the release on failure too would close it.
5. The follow-up paykitPaymentRequestRepo.refresh() after payCovered starts a payment, and synchronizeAfterSubscriptionAction, are full intakes outside the hold with no allowance refresh after them. An allowance acceptance and a new request from that contact landing in one of them can still present the request manually against the stale PROPOSED allowance. Nothing is paid twice.
6. If saving the cleared payment list version fails, takePaymentListVersion() still returns the entry, because updateLocalState() swallows the save error. The stored version stays, so a later node failure event can release it again and clear another payment's claim on the same version. The claim should be saved before the release goes ahead.
7. The test a payment list given back by a failed send is not given back again by the node's failure event settles after autoPay returns, so it never reaches the interleaving it names (an event handled between failUnsent's release and its record). Settling from inside a releasePaymentList answer would reach it.

The double release of a payment list, first listed here, is fixed in #1340 at d6b83b5.

Expected behavior

Held and tapped requests present as soon as the allowance update ends, whether or not the refresh succeeded; every request intake runs under the coverage hold; a payment list is released only after its claim is saved; and coverage counts only allowances that can pay.

Bitkit Version

Unreleased: allowances branch of #1340 at 480ae3a.

Reproducibility

From the code paths.