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

**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 #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.

Start by reading the linked Tier-1 checklist in #437 and the referenced coverage-map discussion in #532 to understand the replication-link model and existing backlog signals. Identify the core produce-side state that can distinguish an idle link from queued transactions blocked on a peer. Done means operators can distinguish those states without receive-side timestamps; the issue also references a scrapable metric under #437 Tier 2 / harper#1636.

Written by the indexing model from the issue text.