docs(mesh): sweep for ClusterClient deletion — Dps|Grpc only, CentralContactPoints retired

Task 3.2 of the ClusterClient->gRPC migration. Sweeps the docs that still
described the Akka ClusterClient transport as live, following its Phase 3
deletion (this branch): MeshTransport:Mode is now Dps (pair-local DPS) or
Grpc (cross-mesh unary calls) only, ClusterClient fails validation loudly,
CentralContactPoints is deleted (not superseded), and the split-topology
validator requires exactly Grpc rather than ClusterClient.

- docs/Configuration.md: rewrite the MeshTransport section — table,
  dark-switch/PSK-seeding prose, listener sharing (:4056 driver-role,
  :4055 admin-role), remove the "shipped dark, cutover pending" framing.
- docs/Redundancy.md: replace the Dps/ClusterClient transport table with
  Dps/Grpc, fix the Phase 6 CentralCommunicationActor + validator bullets.
- docs/Telemetry.md: fix stale ClusterClient cross-refs, add a note that
  the driver-role telemetry listener also hosts NodeCommandService.
- docs/v2/config-db-schema.md: one-line "(retired: ...)" annotation on the
  historical AkkaPort/GrpcPort note — left as a historical record otherwise.
- CLAUDE.md: rewrite "## Mesh command transport (MeshTransport)" for the
  post-deletion world (no ClusterClient/receptionist, per-node gRPC dial,
  fire-and-forget semantics unchanged) and fix two Phase 6 bullets.

deferment.md has no mesh-transport mentions; left untouched.

docs-only change; `dotnet build ZB.MOM.WW.OtOpcUa.slnx` stays green (0
errors) after the edit.

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

docs/Telemetry.md

@@ -39,10 +39,20 @@ mirrors the inversion ScadaBridge already uses for the same problem (its `SiteSt
 A fused `admin,driver` node both hosts (as driver) and dials (as admin) — it dials itself plus its
 redundant pair peer, the same way central dials site nodes.
 
+**This same driver-role listener also hosts the mesh gRPC command-plane ingress.** Whenever
+`Telemetry:GrpcListenPort > 0`, the node maps both `TelemetryStreamGrpcService` (this stream) and
+`NodeCommandService` (central→node commands under `MeshTransport:Mode=Grpc` — see
+[`docs/Configuration.md` § `MeshTransport`](Configuration.md#meshtransport-centralnode-command-transport))
+on the one port. They share it rather than each claiming its own, since both are dialled by the same
+central admin nodes and a second cleartext h2c port would buy nothing but another firewall rule.
+`NodeCommandService` is gated by its own `MeshCommandAuthInterceptor`/`GrpcPsk` bearer, independent
+of this stream's `Telemetry:ApiKey`.
+
 Central discovers driver-node telemetry endpoints from the `ClusterNode` table (`Host` +
 `GrpcPort`, the latter added in Phase 1 for exactly this purpose) — the same DB-sourced discovery
-Phase 1's ack set and Phase 2's `ClusterClient` contact set already use. No shared gossip
-membership is required to find or dial a node.
+Phase 1's ack set and Phase 2's gRPC command dial already use (see
+[`docs/Configuration.md` § `MeshTransport`](Configuration.md#meshtransport-centralnode-command-transport)).
+No shared gossip membership is required to find or dial a node.
 
 ## The dark switch
 
@@ -139,8 +149,8 @@ each for a distinct, settled reason:
   nothing here for a per-node gRPC stream to carry. Revisit in Phase 6, once central genuinely
   loses gossip visibility of site nodes and needs another way to know a pair's membership.
 - **`deployment-acks`** — already migrated, but onto a different transport: it rides the Phase 2
-  `ClusterClient` transport (`MeshTransport:Mode=ClusterClient`) as a command-plane reply, not an
-  observability broadcast. It was never a Phase 5 candidate.
+  gRPC command transport (`MeshTransport:Mode=Grpc`, `CentralCommandService.ReportApply`) as a
+  command-plane reply, not an observability broadcast. It was never a Phase 5 candidate.
 
 See [`docs/Redundancy.md`](Redundancy.md#command-transport-centralnode) for how `redundancy-state`
 and the command transports fit together.