Replication observability: produce-side pending — distinguish "nothing-to-send" (idle) vs "cannot-send" (peer waiting/backpressured) #597

Fold-in from Chris Nelson's replication-monitoring wishlist (item #1, 2026-07-15). Promoted out of the #532 coverage-map comment into a tracked sub-issue of #437 (W8) so it can't be skipped when the Tier-1 checklist is worked.

Problem

Receive-side timestamps conflate idle with broken — a link with nothing to send looks the same as a link that has txns queued but cannot deliver them, so we can never alert on lag alone. Core is the only layer that knows whether txns are actually waiting for a peer. Chris called this the single most valuable observability item.

Ask

Expose a first-class produce-side signal per link that distinguishes:

• nothing-to-send — nothing queued, link legitimately idle, and
• cannot-send — txns queued/pending and blocked on the peer (peer waiting / backpressured / down).

This is the produce-side complement to #437 Tier-1 "Audit/transaction-log backlog depth (pending between cursor and head)" — backlog depth answers how much, this answers why it isn't draining.

Acceptance criteria

• An operator (and a scrapable metric under Replication W8: Observability & metrics pipeline #437 Tier 2 / harper#1636) can tell "link idle" apart from "link has pending txns it cannot send" without inferring from receive-side timestamps.

🤖 Filed by KrAIs on behalf of Kris.