Hold work a private reply creates until the next block

[p0mvn]

Summary

Follow-ups to the review of #999, where a private reply could still change what the wallet asks at the same block. Stacked on #999 and pinned to two draft wallet-libraries PRs: zakura-core/wallet-libraries#212 (receipt lookups a reply queues wait for the next chain tip) and zakura-core/wallet-libraries#213 (window growth is watched from the next recovery target), which is stacked on #212.

• Library pin. Every wallet-libraries dependency moves to the head of Redesign the contacts (address book) surfaces #213. The library adds an in-memory transparent PIR session; each wallet now shares one across all its database handles, as it already shares the Enhance session, so the handle that queues work and the one that lists it agree.
• Receipt lookups wait for the next block. A receive or spend that private recovery stores queues its receipt lookup, and the receipt service no longer sees it in the same sync, even when the receipt is open.
• Same-block catch-up asks about the same addresses. After a lagging or busy reply, a catch-up pass at the same block watches the addresses the first pass watched; a forged receive near the window's end is watched from the next block.
• Recovery-created Enhance work waits too. Enhance queries and status lookups that a recovery reply creates are recorded like the ones other replies create, so a sync resumed at the same block neither asks them nor counts them towards a restart.
• Stale-routing retry. After a 409/410, the retry asks the batch's rows that were not yet asked, instead of re-reading the wallet. A reply that resolved or rerouted another request in the batch no longer changes what is asked again. A request that was already resolved is asked again and changes nothing.
• Stuck retry flag. Expired service waits are dropped when recovery is off for the sync, when the wallet's saved policy is public, or when a policy change stops a run before it reaches every account. Before this, the tip poll could start a sync every 10 seconds for a recovery that would never run.
• Receipt display. A lookup the wallet gave up on now reads "Details unavailable", with no loading icon and no "will update" promise. Also fixes a stale comment about work that history replies find.

Breaking changes

None for users. One build change: zcash_voting still pins an older wallet-libraries revision through git. To keep a single copy of the wallet crates, a git patch moves its zakura-wallet-lib to the same revision. Cargo rejects a patch that points at the same URL, so every wallet-libraries dependency now names the repository with a git@ user (https://git@github.com/...). GitHub serves that anonymously. Both the patch and the user part can go once zcash_voting moves to the same revision. When #212 and #213 merge, this repins to wallet-libraries main.

Validation

Tests came first in their own commit, and each failed on #999's head at its target assertion:

• A recovered receive is looked up only from the next block: on Reduce reply-dependent traffic in private recovery #999 the receipt is looked up in the same sync ("not in the sync that recovered the receive").
• A same-block catch-up asks about what the first pass asked: on Reduce reply-dependent traffic in private recovery #999 the catch-up after a forged receive watches more addresses ("the catch-up asks about the first pass's addresses").
• An Enhance query a recovery reply creates waits for the next block: on Reduce reply-dependent traffic in private recovery #999 it counts towards a restart ("the query the recovery reply created is not counted").
• A stale-routing retry asks the same rows whatever a reply cleared: on Reduce reply-dependent traffic in private recovery #999 the retry asks fewer rows after a reply that moved its transaction to public enhancement ("the retry asks the same rows").
• Turning recovery off leaves no retry due: on Reduce reply-dependent traffic in private recovery #999 the retry flag stays set ("no sync is due for a recovery that is off").
• Desktop receipt for a given-up lookup: on Reduce reply-dependent traffic in private recovery #999 the "Details unavailable" row without the loader is not found.

Vizor has no PR test CI, so these are local results at this branch's head:

• Rust, focused groups: enhancement 103 passed / 4 failed, transparent ledger 142 passed, transparent details 41 passed / 2 failed, private recovery reorg 5 passed, transparent recovery 19 passed, history golden 40 passed, private recovery 6 passed, private shielding 6 passed.
• All six failures also fail on Reduce reply-dependent traffic in private recovery #999's head and are not caused by this change. Four Enhance tests expect no first-query delay, but Reduce reply-dependent traffic in private recovery #999's library pin brought back the random 0–75 second delay. Two transparent-details tests fail building a transaction ("Orchard builder not available").
• Dart: the sync provider and transparent details tests, 123 passed in the default lane and 55 passed in the mobile lane.
• The non-test library build has no warnings. Flutter analyze reports no issues on the changed Dart code.

🤖 Generated with Claude Code