docs(mesh-phase5): telemetry stream — Telemetry.md, config keys, supersede §6.3, program status

Claude-Session: https://claude.ai/code/session_01GASWkNEi68FSCtvr6rLoEW

docs/Redundancy.md

@@ -465,6 +465,15 @@ are untouched, and `redundancy-state` itself stays on DPS (it is bidirectional a
 `Cluster.State`, which makes it genuinely mesh-bound — the hardest remaining dependency before the
 meshes can split).
 
+**Observability telemetry took the opposite path (Phase 5).** The four live-panel channels
+(`alerts`, `script-logs`, `driver-health`, `driver-resilience-status`) moved off DPS onto a
+dedicated gRPC server-streaming contract — each driver node hosts, central dials in — selected by
+`Telemetry:Mode`/`TelemetryDial:Mode` (default `Dps`). `redundancy-state` is deliberately **not**
+part of that migration: it stays on DPS in every mode because it is pair-local and Cluster.State-built,
+not a fleet-wide observability broadcast. See [`docs/Telemetry.md`](Telemetry.md) for the full
+architecture and [`Configuration.md` § `Telemetry`/`TelemetryDial`](Configuration.md#telemetry--telemetrydial-live-telemetry-transport)
+for the config keys.
+
 **Config bytes travel out-of-band (Phase 3).** Commands stay on one of the two transports above, but
 the *configuration artifact itself* does not ride any Akka message — `DispatchDeployment` is
 payload-free (`DeploymentId` + `RevisionHash`). Under `ConfigSource:Mode = FetchAndCache` (see