Web TLS certificate expiry should raise a service self-alert (headless: startup-log warning isn't enough) #3514

Context

When the web dashboard is LAN-exposed with web.network.tls, the certificate's expiry is surfaced only two ways today:

• a startup-log warning within 30 days of notAfter (DarlingWebTls.ExpiryWarning, emitted once in DarlingWebHostService.StartWebHostAsync), and
• the --status CLI summary line.

Both require someone to go look. On a headless service that can run untouched for months, neither re-fires between restarts — so the practical failure mode is: the cert expires, the LAN dashboard fails closed to loopback-only + Critical log (correct — it never downgrades to plain HTTP), and the operator finds out when they can no longer reach it.

Proposal

Raise cert-near-expiry / expired as a fleet service self-alert through the existing DarlingSelfAlertEvaluator machinery — the same delivery path (email/webhook, cooldown, mute) as Retention Held and the stale-mute self-alert (#3306), which are the same "the operator must act and the only symptom is silence" shape.

• Warn at the existing 30-day threshold (DarlingWebTls.ExpiryWarningDays); escalate to Critical once expired (the dashboard is already loopback-only by then).
• Re-evaluate on the alert sweep, not just at web-host startup, so it fires without needing a restart.
• Only when web.network.tls is configured — loopback-only / no-TLS installs have no cert to watch.

Not this issue

• The default-is-plain-HTTP discovery gap (LAN exposure with no TLS): the exposure is already logged as a WARN; whether to nudge or require TLS on LAN exposure is a separate call.
• Docs: the renew-or-it-goes-loopback behavior is already documented in darling.sample.json; a short deployment-doc mention for anyone LAN-exposing would round it out.

Found while wiring web.network.tls on the dogfood box (a 10-year self-signed cert, so it won't bite locally — but a CA-issued cert on a real deployment rotates on a normal schedule, which is exactly when this matters).