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>