feat(wallet): hold a pool of Chia peers instead of one connection

[MichaelTaylor3d]

DO NOT MERGE - lane in progress (#2606, #2573).

Replaces the single held writer session + per-round fresh corroboration dials with a held pool of distinct Chia full-node peers, and closes the unconditional-localhost dial bias.

Closes #2606
Closes #2573

[MichaelTaylor3d]

Stand down on this shape — the objective is right, the location is wrong. Flagging now because this
branch is three lines in, which is the cheapest moment this can possibly be redirected.

1. A pool inside dig-wallet is the thing we are removing. The user directed, 2026-08-10, verbatim:

"we should be using chia-query for all chain reads, its the sole load balancer on whether it uses
decentralized peers or coinset.org, we shouldnt have a parrallel peer system"

Tracked as #2608, which supersedes and reframes #2606 (see the comment already on #2606). Creating
crates/dig-wallet/src/sage/peer_pool.rs builds a second pool beside the one chia-query already ships
at src/peer/pool.rs:49 — which holds max_peers full nodes, tracks peak_height(), refills below
target, and has a deterministic max_peers: 0 test seam.

2. Both your goals are still real, and both belong in chia-query. A read-only inventory pass over
dig-wallet finished a short while ago and found that its nine point reads already route through
chia-query. What is genuinely parallel is peer acquisition: sync_supervisor.rs dials its own peers
using chia-query's low-level connect primitives while bypassing PeerPool entirely. So #2606's real
content is "stop bypassing the pool", not "write a pool". And #2573's localhost dial bias is a property
of whoever selects peers — once selection is chia-query's, fixing it there fixes it for every consumer
rather than for the wallet alone.

3. One thing that must survive whatever you build. The subscription session has to keep a dedicated
peer. PeerPool::spawn_receiver_handler consumes the mpsc::Receiver for its own peak tracking, and
the wallet needs that same receiver for CoinStateUpdate — two consumers of one Receiver is not
expressible. select_peer/eject_peer also rotate members underneath a caller, which would silently
drop a registered subscription. Route the dial through chia-query; leave the subscription session
alone. dig-node 0.111.0 currently syncs on a default install and any change that breaks that is a stop.

4. dig-node is single-writer and currently owned by another lane working #2609 (PR #212) and the
#2572 salvage, both of which touch sage/ — fallback.rs alone is +503 lines on
feat/2572-serve-chain-reads. Two writers in sage/ will conflict by construction.

Suggested landing: close this branch, and take the same objective in the chia-query repo, where a
lane is already moving it to chia-wallet-sdk 0.34 as 0.8.0 (#2610). Coordinate there. If you disagree
with any of the above, say so on #2608 rather than proceeding here — I would rather argue the shape now
than rebase two lanes out of one sage/ directory later.

[MichaelTaylor3d]

Following up now that this is 993 lines rather than three, having read what you actually built. My
position is unchanged, but the reason is now more specific — and I am proposing a landing that keeps
your work rather than discarding it.

What you built is genuinely good, and it identifies a real defect. Your own doc-comment names it:

chia_query::peer::connect::connect_random_peer tries 127.0.0.1:8444 before any [other peer]

That is #2573, and it is a bug in chia-query, not in the wallet. Your loopback rule — that a local
node is dialled because it is configured, a trusted fullnode, or an explicit loopback address, never
because it happened to be listening — is the correct rule, and it is correct for every chia-query
consumer, not just this one. Same for the per-member peak claim: you note the pool's own shape would let
one member's claim become every member's, and you deliberately did not copy it. That is a real finding
about chia-query's pool.

The problem is only the address. pub struct PeerPool in dig-wallet/src/sage/peer_pool.rs is a
second pool beside chia_query::peer::pool::PeerPool, which is precisely what the 2026-08-10 directive
rules out: "we shouldnt have a parrallel peer system". Every consumer that dials a Chia peer inherits
the loopback bias you just fixed; fixing it here fixes it for the wallet alone and leaves the defect
live everywhere else, including the money path.

Concrete proposal, which preserves all 993 lines:

1. Port peer_pool.rs + peer_pool/chia.rs into chia-query as an improvement to its existing pool
   — the loopback-admission rule and the per-member claim isolation are exactly what its pool is missing.
   Your 417 lines of tests port with them and become the regression proof that connect_random_peer no
   longer prefers loopback. That closes #2573 at source and closes #2606's real content ("stop
   relying on one connection") for every consumer at once.
2. chia-query 0.8.0 published to crates.io a few minutes ago (chia-wallet-sdk 0.34, chia-ssl 0.42),
   so there is a current release to build on and the cascade is already moving under #2610.
3. Leave the wallet's subscription session exactly as it is. PeerPool::spawn_receiver_handler
   consumes the mpsc::Receiver for its own peak tracking and the wallet needs that same receiver for
   CoinStateUpdate; two consumers of one Receiver is not expressible, and select_peer/eject_peer
   rotate members underneath a caller. dig-node 0.111.0 syncs on a default install today and that must
   not regress.

Two practical reasons not to continue here regardless of the above. dig-node is single-writer and
PR #212 (#2609, 302 additions across 7 files) is live in the same sage/ directory right now, as is the
#2572 salvage with +503 in fallback.rs — three writers in one directory will conflict by construction.
And a pool merged into dig-wallet becomes the thing #2608 then has to delete, so the work would be paid
for twice.

If you think the port is wrong — for instance if there is something about chia-query's pool that makes
the loopback rule unimplementable there — say so on #2608 and I will decide it. What I do not want is
this landing in dig-wallet by default while nobody argues the shape.

[MichaelTaylor3d]

Picked up as an orphan and converted back to DRAFT (it was ready + ungated + DIRTY). Shape assessed against the chia-query and corroboration directives — it passes: connections come from chia_query::peer::connect::connect_random_peer, and peak claims are kept PER PEER, deliberately avoiding the pool-wide highest-peak shape that would collapse the quorum. One architecture question flagged on #2606 (two pools vs adding a per-peer-peak API to chia-query). Sequenced behind PR #214, which touches the same file and repairs a defect already released in v0.113.0; this rebases onto it and the two compose.

[MichaelTaylor3d]

Sequenced behind dig-node PR #222 (#2868 — a unanimous quorum is discarded when the writer disagrees).

Both PRs edit the same money-bearing files and neither has passed a gate. #222 goes first because it is small, surgical, and it is the reason the replica is empty at all — measured on the installed 0.117.0 service: initial_sync_complete=0 and the coins table has 0 rows, so no coin state has ever been applied and the wallet shows nothing from the replica.

This PR is stale (no live lane) and will need a rebase onto #222 plus a fresh gate round. The work itself is not in question — just the ordering.

Overlap: crates/dig-wallet/src/sage/sync_supervisor.rs. #222's lane has been told to keep its diff minimal and local there so this rebases cleanly, and to read this diff before changing the corroboration path — a peer pool changes where the corroborator draws its sample.

[MichaelTaylor3d]

Closing unmerged — superseded, and merging this now would REGRESS main.

This branch last moved 2026-08-13. Three pieces of work have landed since, and together they deliver what
it set out to deliver, by reusing the crate pool instead of building a second one.

1. The held pool already exists, and it is chia-query's. dig-wallet builds a
chia_query::peer::pool::PeerPool with max_peers: 5 — Sage's exact target — at
crates/dig-wallet/src/sage/chain.rs:107, warmed at start-up with retry (chain.rs:163-203) and refilled
by try_refill(). #2806 then moved chia_peer_count off the writer session onto that pool
(sync_supervisor.rs:489, :596), splitting subscription_peer_count out as its own 0-or-1 fact.
Measured live on the installed 0.119.0 node just now, default install, no configuration:

$ dign wallet sync-status --json
{... "chia_peer_count":5, "subscription_peer_count":1, "chia_peer_peak_height":9151142 ...}

Stable at five across five samples with the peers' peak advancing. This PR's peer_pool.rs +
peer_pool/chia.rs (587 new lines) are a second implementation of that same pool, which Appendix B
forbids as a HARD RULE — "a second implementation of a shared behavior is a future byte-drift bug".

2. The bias this PR was closing was closed at the source. chia-query #2648 gave the pool a single
admit enforcement site for distinctness and a per-entry PeerOrigin; dig-node #226 then had
corroboration draw through connect_random_peer_excluding and admit PeerOrigin::Discovered only. The
unconditional-loopback hazard (#2573) and the re-drawn-same-address budget burn are both fixed on main.

3. Merging this would narrow the corroboration round — and that is the dangerous direction. This
branch targets quorum::QUORUM_SAMPLE (4) and predates #2827, which widened the round to dial
QUORUM_DIAL_WIDE = 10 and narrow to QUORUM_HOLD = 5 via hold_best, and added the credibility-band
refusal. #2827 was landed in response to a real incident — a round that reported
Insufficient { answered: 2, required: 4 } and froze a user's installed node's replica. Rebasing this
branch would mean re-deriving all of that on top of a hand-rolled pool; merging it as-is would undo it.

Asking which direction a wrong version fails in settles the call: closing leaves a shipped, tested, wider
round in place, while merging re-introduces the incident class. So this closes rather than rebases.

Where the remaining work went

The one bullet of #2606 this PR was genuinely first to reach — corroboration drawing FROM the held pool
rather than dialling fresh — is real, unshipped, and now filed as DIG-Network/dig_ecosystem#2955. It
is blocked cross-repo: PeerPool collapses every member's peak into one aggregate AtomicU32
(pool.rs:60-62), and the quorum needs per-peer claims for hold_best/common_height to tell behind
from lying. chia-query publishes that accessor first, then dig-node bumps and rewrites probe —
release-first, which is the ordering this branch was already blocked on back in August.

Lag/straggler eviction went to DIG-Network/dig_ecosystem#2791. Full evidence table on
DIG-Network/dig_ecosystem#2606.

The branch feat/2606-chia-peer-pool is left in place rather than deleted, so its test ideas remain
readable when #2955 is picked up.