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/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>