Replication observability: time-at-full-buffer counter (alertable backpressure)

**Fold-in from Chris Nelson's replication-monitoring wishlist (rider, 2026-07-15).** Promoted out of the #532 coverage-map comment into a tracked sub-issue of #437 (W8).

## Problem
The raw back-pressure percentage **oscillates 0–100 on busy meshes**, so the monitoring side has to smooth it downstream before it's usable — a smoothing step that hides exactly the sustained-full condition we want to alert on.

## Ask
Add a **monotonic time-at-full-buffer counter** per link (seconds spent with the send buffer full). A counter is directly alertable (`rate() > threshold`) with no downstream smoothing, unlike the oscillating instantaneous %.

## Acceptance criteria
- Per-link cumulative time-at-full-buffer is queryable in `cluster_status` and scrapable per peer (harper#1636), and an alert can fire on sustained backpressure without client-side smoothing.

---
🤖 Filed by KrAIs on behalf of Kris.

Start with the cluster_status entry point and trace the per-peer scraping path referenced by harper#1636; review the related context in #437 and #532. Determine how each link’s full-buffer state is represented. Done means cumulative time-at-full-buffer is queryable per link, exposed through cluster_status and peer scraping, and supports sustained-backpressure alerts without client-side smoothing.

Written by the indexing model from the issue text.