refactor(comm): retire ClusterClient naming after the gRPC cutover

Phase 4 of the ClusterClient -> gRPC migration deleted the Akka transports
but left the naming behind: `ClusterClientSiteAuditClient` was transport-
agnostic and worked unchanged, so it survived the deletion under a name
that now describes a transport the repo no longer has. Same for a scatter
of doc-comments still framing gRPC as "the new transport" beside an Akka
one that is gone.

Renames it to `SiteCommunicationAuditClient` (and its test file) and
rewrites the stale comments to describe the single transport that exists.
Also tightens CLAUDE.md: drops the self-describing directory listing and
the 27-component enumeration in favour of the non-obvious parts only.

Behaviour-neutral: names and prose only. Recorded as the Phase 4
follow-up in docs/plans/2026-07-22-clusterclient-to-grpc-plan.md.

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/CentralControlDtoMapper.cs

@@ -16,8 +16,8 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// <para>
 /// The seven pairs mirror, one for one, the seven messages
 /// <c>SiteCommunicationActor</c> forwards to <c>/user/central-communication</c> over
-/// Akka <c>ClusterClient</c> today. Both transports carry the SAME message types
-/// end-to-end — central's handlers are untouched by the migration — so this mapper is
+/// the control plane. The in-process and wire representations carry the SAME message types
+/// end-to-end — central's handlers were untouched by the migration — so this mapper is
 /// the only place the two representations meet, and a field that does not survive a
 /// round-trip here is a field the gRPC transport silently drops.
 /// </para>

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/CentralControlGrpcService.cs

@@ -14,7 +14,7 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// <summary>
 /// Central-hosted gRPC face of the seven site→central control messages
 /// (<c>Protos/central_control.proto</c>). Decodes each request onto the SAME in-process
-/// message type the Akka <c>ClusterClient</c> path already carries, <c>Ask</c>s
+/// message type the removed Akka <c>ClusterClient</c> path used to carry, <c>Ask</c>s
 /// <see cref="Actors.CentralCommunicationActor"/>, and encodes the reply back.
 /// </summary>
 /// <remarks>
@@ -26,8 +26,8 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// </para>
 /// <para>
 /// <b>Zero handler logic lives here.</b> Every RPC lands on a receive
-/// <c>CentralCommunicationActor</c> already implements for the ClusterClient path, so the two
-/// transports cannot drift in behaviour: the actor is the single implementation, and this class
+/// <c>CentralCommunicationActor</c> already implements, so transport and handler cannot drift
+/// in behaviour: the actor is the single implementation, and this class
 /// is a codec plus an <c>Ask</c>. That is also why the service takes the actor through
 /// <see cref="SetReady"/> rather than resolving anything from DI — the actor is created by the
 /// host's Akka bootstrap, not by the container.
@@ -36,8 +36,8 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// <b>Fault semantics deliberately differ from <see cref="SiteStreamGrpcServer"/>'s ingest
 /// RPCs.</b> That server answers a failed audit ingest with an EMPTY <c>IngestAck</c>; this one
 /// fails the call with a non-OK status. Both leave the site's rows <c>Pending</c> for the next
-/// drain, so the outcome is the same — but this service replaces the ClusterClient path, whose
-/// documented behaviour is to propagate the fault (<c>CentralCommunicationActor</c>'s
+/// drain, so the outcome is the same — but this service replaced the ClusterClient path, whose
+/// documented behaviour was to propagate the fault (<c>CentralCommunicationActor</c>'s
 /// <c>HandleIngestAuditEvents</c> pipes a <c>Status.Failure</c> back), and preserving that keeps
 /// a lost batch visible as a failure rather than as a successful call that acked nothing.
 /// </para>
@@ -94,8 +94,8 @@ public sealed class CentralControlGrpcService : CentralControlService.CentralCon
     /// actor exists and can receive, NOT that every downstream singleton proxy
     /// (<c>notification-outbox</c>, <c>audit-log-ingest</c>) has registered itself yet. Those
     /// register moments later in the same startup path, and the actor already answers a call
-    /// that beats them with the same "not available, retry" reply it gives on the ClusterClient
-    /// path — so gating readiness on them would add nothing but a longer window in which sites
+    /// that beats them with a "not available, retry" reply
+    /// — so gating readiness on them would add nothing but a longer window in which sites
     /// see <see cref="StatusCode.Unavailable"/>.
     /// </remarks>
     /// <param name="centralCommunicationActor">The central communication actor.</param>

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/GrpcCentralTransport.cs

@@ -11,8 +11,8 @@ using AkkaStatus = Akka.Actor.Status;
 namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 
 /// <summary>
-/// The <see cref="ICentralTransport"/> that carries the seven site→central sends over gRPC — the
-/// migration target for the Akka <c>ClusterClient</c> path. Each method encodes the message with
+/// The <see cref="ICentralTransport"/> that carries the seven site→central sends over gRPC —
+/// the replacement for the removed Akka <c>ClusterClient</c> path. Each method encodes the message with
 /// <see cref="CentralControlDtoMapper"/>, dials <c>CentralControlService</c> through the sticky
 /// <see cref="CentralChannelProvider"/>, and delivers the decoded reply (or a transient-failure
 /// signal) to the waiting Ask.

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/GrpcSiteTransport.cs

@@ -81,7 +81,7 @@ public sealed class GrpcSiteTransport : ISiteCommandTransport
         }
         catch (SiteChannelUnavailableException)
         {
-            // Parity with the Akka "no ClusterClient for site" path: warn and drop, so the caller's
+            // Parity with the removed Akka "no ClusterClient for site" path: warn and drop, so the caller's
             // Ask times out. Central never buffers.
             _logger.LogWarning(
                 "No gRPC channel for site {SiteId}; dropping {Message} (caller's Ask will time out)",

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/SiteCommandGrpcService.cs

@@ -22,7 +22,7 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// </para>
 /// <para>
 /// <b>Coexistence — server-side only.</b> This makes the site ALSO listen on gRPC for commands;
-/// nothing central flips to gRPC here (that is T1B.3). Central still dials sites via ClusterClient.
+/// this was the server half, landed before central was flipped to dial it (T1B.3).
 /// </para>
 /// <para>
 /// <b>Fire-and-forget.</b> The Akka path never acks <c>UnsubscribeDebugView</c>, but a unary RPC

src/ZB.MOM.WW.ScadaBridge.Communication/Grpc/SitePairChannelProvider.cs

@@ -9,7 +9,7 @@ namespace ZB.MOM.WW.ScadaBridge.Communication.Grpc;
 /// <summary>
 /// Raised when a site has no usable gRPC channel — an unknown site, or a site with neither
 /// <c>GrpcNodeAAddress</c> nor <c>GrpcNodeBAddress</c> configured. The gRPC transport treats this
-/// the way the Akka path treats "no ClusterClient for site": warn and drop, so the caller's Ask
+/// the way the removed Akka path treated "no ClusterClient for site": warn and drop, so the caller's Ask
 /// times out (central never buffers).
 /// </summary>
 public sealed class SiteChannelUnavailableException(string siteId)