refactor(mesh): step 6 — delete the ClusterClient mode value; split topology now requires Grpc

MeshTransportOptions.ModeClusterClient is gone. MeshTransportOptionsValidator accepts Dps or
Grpc and nothing else, so a node left carrying the string "ClusterClient" is now REFUSED at
boot naming MeshTransport:Mode and both remaining values — deliberately fail-closed rather
than falling back to Dps, which on a split-topology node would deliver nothing at all. A new
fact pins exactly that.

SplitTopologyTransportValidator tightens from an allow-list of two to Grpc only, as its own
comment said it would once ClusterClient was deleted. Dps on a cluster-role node stays
refused; the rule is still an explicit allow-list, so a typo'd mode fails too.

Tests: the two ClusterClient-mode facts in MeshTransportOptionsValidatorTests are deleted
(their Dps siblings already assert the same rule for the one remaining non-Grpc mode), the
SplitTopology fixtures move to Grpc, and the three-mode Theories in
ControlPlaneStarterOrderTests / CentralCommunicationActorTests become two-mode.

tests/Server/ZB.MOM.WW.OtOpcUa.ControlPlane.Tests/Communication/CentralCommunicationActorTests.cs

@@ -515,17 +515,16 @@ public class CentralCommunicationActorTests : ControlPlaneActorTestBase
 
     [Theory]
     [InlineData(MeshTransportOptions.ModeDps)]
-    [InlineData(MeshTransportOptions.ModeClusterClient)]
     [InlineData(MeshTransportOptions.ModeGrpc)]
     public void The_known_cluster_gate_is_published_in_every_transport_mode(string mode)
     {
         // Replaces an earlier fact asserting the OPPOSITE, whose premise did not survive Phase 1B: the
         // gate feeds CentralCommandAuthInterceptor, which is registered on every admin node, and the
         // ack service it protects is mapped by LISTENER PORT — neither consults MeshTransport:Mode.
-        // Gating the publication on Grpc meant a dark-switch rollback to Dps left that endpoint
-        // serving with a permanently inactive gate, silently restoring both the timing
-        // oracle and the pre-authentication store/audit flood. The set is central's cluster
-        // inventory, not transport state.
+        // Gating the publication on Grpc meant a rollback to Dps left that endpoint serving with a
+        // permanently inactive gate, silently restoring both the timing oracle and the
+        // pre-authentication store/audit flood. The set is central's cluster inventory, not
+        // transport state.
         var factory = NewInMemoryDbFactory();
         SeedGrpcCluster(factory, "C1", ("host-a:4053", "host-a", 4056, true, false));
         var psk = new RecordingPskProvider();

tests/Server/ZB.MOM.WW.OtOpcUa.ControlPlane.Tests/Communication/ControlPlaneStarterOrderTests.cs

@@ -55,11 +55,10 @@ public sealed class ControlPlaneStarterOrderTests
 {
     [Theory]
     [InlineData(MeshTransportOptions.ModeDps)]
-    [InlineData(MeshTransportOptions.ModeClusterClient)]
     [InlineData(MeshTransportOptions.ModeGrpc)]
     public async Task An_admin_node_boots_with_the_real_mesh_dependency_graph(string mode)
     {
-        // Every mode, because the eager resolve was mode-independent: the starter resolved both
+        // Both modes, because the eager resolve was mode-independent: the starter resolved both
         // dependencies before anything looked at MeshTransport:Mode, so Dps — the DEFAULT, and the
         // rollback target — died exactly like Grpc did.
         using var host = BuildAdminHost(mode);
@@ -82,7 +81,6 @@ public sealed class ControlPlaneStarterOrderTests
 
     [Theory]
     [InlineData(MeshTransportOptions.ModeDps)]
-    [InlineData(MeshTransportOptions.ModeClusterClient)]
     [InlineData(MeshTransportOptions.ModeGrpc)]
     public async Task The_deferred_dependencies_are_resolved_and_used_once_the_host_is_up(string mode)
     {
@@ -90,7 +88,7 @@ public sealed class ControlPlaneStarterOrderTests
         // silent one, with the known-cluster gate permanently unpublished and the dialer permanently
         // absent. So this asserts the far end of the deferral: the actor resolved the PSK provider
         // FROM THE CONTAINER and drove it, through the ordinary contact-refresh path. A Theory over
-        // all three modes because publication is mode-independent (the gate follows the endpoint).
+        // both modes because publication is mode-independent (the gate follows the endpoint).
         //
         // The provider is registered as a TYPE with an ISecretResolver constructor, so the resolve
         // walks the same registry-bound chain the production MeshPskProvider does — which makes