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.

tests/ZB.MOM.WW.ScadaBridge.CentralUI.PlaywrightTests/Deployment/DeploymentFixture.cs

@@ -11,8 +11,8 @@ namespace ZB.MOM.WW.ScadaBridge.CentralUI.PlaywrightTests.Deployment;
 ///
 /// <para>
 /// <b>Why <c>site-a</c> and not a throwaway site:</b> the deploy / enable / disable
-/// actions relay to the owning site over the Akka <c>ClusterClient</c>. An unknown
-/// site identifier has no registered <c>ClusterClient</c>, so the relay only
+/// actions relay to the owning site over the gRPC site command plane. An unknown
+/// site identifier has no reachable gRPC endpoint, so the relay only
 /// resolves on a slow 10-second timeout (and never surfaces a fast failure toast).
 /// To exercise the real action path, the ephemeral instances must therefore live
 /// on a <em>real, running</em> site — <c>site-a</c> — rather than a fixture-created