docs: fix two stale mesh-program claims found in review (Phase 5 gate passed; Phase 6 ended fleet-wide gossip)

Review of the ClusterClient-deletion docs sweep (406b1ae5) flagged two
pre-existing staleness items in the swept files, unrelated to ClusterClient
but caught while touching the same passages:

- docs/Telemetry.md: the Phase 5 telemetry section's Status line still said
  "code-complete ... live gate has not yet run" — the gate PASSED 2026-07-23
  (merge 35552a96), already recorded in CLAUDE.md. Updated to match.
- docs/v2/config-db-schema.md: the AkkaPort/GrpcPort note asserted in the
  present tense that "central shares a gossip ring with every node," which
  Phase 6 (2026-07-24) ended — central now runs one 2-node Akka mesh per
  application Cluster and reaches a site pair only over gRPC. Reworded the
  premise to past tense so it no longer contradicts the ClusterClient-deleted
  parenthetical sitting right after it.

docs-only; dotnet build ZB.MOM.WW.OtOpcUa.slnx stays green (0 errors).

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

docs/Telemetry.md

@@ -259,7 +259,7 @@ otherwise), and `Grpc` mode on either side requires a non-empty `ApiKey` — bot
   naturally node-sourced and fleet-wide-fanned, so putting central in the client role — dialing out
   to each node by its `ClusterNode`-recorded address — is what lets telemetry survive the mesh split
   cleanly: central never needs cluster membership with a site's mesh to keep watching it.
-- **Status:** code-complete on `feat/mesh-phase5`; the live gate (flip the docker-dev rig to `Grpc`,
+- **Status:** merged to `master` (`35552a96`); the live gate (flip the docker-dev rig to `Grpc`,
   confirm all panels stay green with the DPS telemetry bridges unspawned, kill-and-reconnect a site
-  node) has not yet run. See `docs/plans/2026-07-22-per-cluster-mesh-program.md` § Phase 5 and
+  node) PASSED 2026-07-23. See `docs/plans/2026-07-22-per-cluster-mesh-program.md` § Phase 5 and
   `docs/plans/2026-07-23-mesh-phase5-grpc-telemetry-stream.md` for the implementation plan.

docs/v2/config-db-schema.md

@@ -174,14 +174,18 @@ CREATE UNIQUE INDEX UX_ClusterNode_Primary_Per_Cluster
 
 These are **the addresses central dials**, not the node's own binding configuration. The node binds
 from `Cluster:Port` in its own appsettings; these columns duplicate that value for a reader that
-cannot see the node's config. Today central shares a gossip ring with every node and does not need
-them — [per-cluster mesh Phase 2](../plans/2026-07-21-per-cluster-mesh-design.md) splits the fleet
-into one mesh per `Cluster`, after which `Host` + `AkkaPort` is how central builds its ClusterClient
-contact points (**retired**: the Akka `ClusterClient` transport was deleted by the
+cannot see the node's config. When this column was added central still shared one gossip ring with
+every node and did not strictly need them; that premise ended at
+[per-cluster mesh Phase 6](../plans/2026-07-24-mesh-phase6-partition-and-colocation.md)
+(2026-07-24), which split the fleet into one 2-node Akka mesh per application `Cluster` — central no
+longer shares gossip with a site pair at all, and reaches it only over gRPC (and, before Phase 6
+finished landing, briefly over the now-deleted Akka `ClusterClient`). `Host` + `AkkaPort` was how
+central would have built `ClusterClient` contact points; that transport was deleted by the
 [ClusterClient→gRPC migration](../plans/2026-08-06-clusterclient-to-grpc-design.md) — central now
-dials `NodeCommandService` at `Host`+`GrpcPort` instead, and `AkkaPort` is Akka remoting only), and
-`GrpcPort` is the Phase 5 telemetry stream **and**, since that migration, the Phase 2 gRPC command
-dial target too — see [`Configuration.md` § `MeshTransport`](../Configuration.md#meshtransport-centralnode-command-transport).
+dials `NodeCommandService` at `Host`+`GrpcPort` instead, and `AkkaPort` is Akka remoting only (still
+needed pair-locally, within a `Cluster`'s own 2-node mesh). `GrpcPort` is the Phase 5 telemetry
+stream target **and**, since that migration, the Phase 2 gRPC command dial target too — see
+[`Configuration.md` § `MeshTransport`](../Configuration.md#meshtransport-centralnode-command-transport).
 
 `AkkaPort` is `NOT NULL DEFAULT 4053` because every node listens on a remoting port — `0` is never a
 truthful value, and rows predating the column must migrate to something real. `GrpcPort` is nullable