Replication observability: cert expiry as a scrapable field

**Replication observability gap — surfaced by Chris Nelson (monitoring), 2026-07-15.**
Child of #430 (Replication epic) / #532 (Monitoring tracking); slot under #437 (W8 observability) Tier 1/2.

## Problem
Replication **cert expiry is invisible**. We already page on *public* cert expiry, but the certs securing replication links have no scrapable field anywhere in `cluster_status`, `hdb_analytics`, or the metrics pipeline. An expired replication cert silently kills a link.

This is the **leading suspect for the 31-day dead links** (see the disconnect-reason-code work) and is the single most *preventable* link killer — an expiry we can see coming is an expiry we page on before it fires.

## Ask
- Expose per-link (and/or per-node) **replication cert `notAfter`** as a field in `cluster_status` and as a scrapable metric (`..._cert_expiry_seconds` with per-peer labels) via the native OpenMetrics endpoint (harper#1636).
- Ideally also the CA/chain expiry if the link presents a chain.

## Acceptance criteria
- Replication cert expiry timestamp is queryable via `cluster_status` and scrapable per peer.
- An expiring replication cert can be alerted on **before** the link dies (parity with public cert paging).

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

Start by tracing how replication data is exposed through cluster_status and the native OpenMetrics endpoint, checking hdb_analytics and the existing public certificate expiry path for related conventions. Done means the replication certificate notAfter is queryable in cluster_status and emitted as a per-peer cert_expiry_seconds metric that can trigger alerts before link failure.

Written by the indexing model from the issue text.