feat(peer): register accepted inbound peers in the connected pool (#3124)

[MichaelTaylor3d]

DO NOT MERGE — WIP, gate round not yet run, and BLOCKED on a dependency.

Consumer half of dig_ecosystem#3124 — https://github.com/DIG-Network/dig_ecosystem/issues/3124

Depends on DIG-Network/dig-gossip#83, which adds the entry point this PR calls.

What

serve_peer_rpc_listener_with accepted, authenticated and served every inbound peer while registering
none of them, so connected_peers under-reported every one. It now adopts each accepted connection
into the dig-gossip pool for the life of its serve loop, and releases the slot when that loop returns.

BLOCKER — the rev pin is temporary

crates/dig-node-core/Cargo.toml currently pins dig-gossip to this lane's BRANCH commit
(f21f993) so the wiring could be compiled and proven. It must be re-pinned to dig-gossip main
after #83 merges, before this leaves draft.

dig-gossip is not published on crates.io (index.crates.io → 404), so a version dependency is not
available today; the git = pin is pre-existing (NC-7 / CLAUDE.md §3.6) and this PR does not resolve
it. Flagged for the orchestrator rather than fixed here — a first publish of the crate is irreversible
and well outside this ticket.

Status

• listener wiring, both call sites
• tests
• re-pin to dig-gossip main
• version bump

Blast radius: to be stated before this leaves draft.

[MichaelTaylor3d]

Ownerless and rotted, not subsumed — measured 2026-08-31

Reconciled on a wake with no live lane on this branch. Recording the state so the next lane resumes
instead of re-deriving it.

Not subsumed. I checked whether main had grown its own inbound adoption while this sat. It has
not: main carries the direction: inbound|outbound reporting (peer.rs:309,331) but nothing that
registers an ACCEPTED peer in the gossip pool. adopt_inbound_peer_in_pool /
release_inbound_pool_slot exist only on this branch. The 128 lines here are still the fix, and the
design note in them — registering by ClosedHandle rather than handing over the session, so adoption
cannot buy the count at the cost of serving the peer — is the part worth preserving through any rebase.

Rotted. Last touched 2026-08-29T04:55Z; main has since advanced through 8b53156, 5df3e34,
bd3d701, 6d6bb7c, 3d15118, 9eb8fbd (0.175.1). Six checks are FAILURE — Rustfmt, Clippy,
Test + coverage, Check version increment, and all four package builds. That set is the signature of
a stale base, not of a defect in the diff; treat it as such and re-measure after the rebase rather than
debugging the current reds.

Two things to do at rebase time, both of which have bitten this repo this week:

• Re-read the version from the file on disk afterwards, never from the commit log.
  git rebase --onto silently DROPS a bump commit whose patch is identical to one already upstream —
  RC=0, no conflict, and a single line reading dropping <sha> ... patch contents already upstream.
  The branch then sits at main's version with no increment and no bump commit left to notice.
• Scan the rebase output for dropping, not only for CONFLICT.

Not selectable right now. dig-node is single-writer and the lane is held by the
https://github.com/DIG-Network/dig_ecosystem/issues/3166 mirror family (#433 / #412 step 8 / #411),
which is the active epic. This is the first candidate once that epic closes — it is a real,
user-visible under-count on a shipped surface, so it does not get dropped, only ordered.