feat(comm): Phase 4 — delete Akka ClusterClient site↔central transport, gRPC-only

ClusterClient→gRPC migration Phase 4 (docs/plans/2026-07-22-clusterclient-to-grpc-plan.md).
Phases 2/3 proved both directions on gRPC; this removes the Akka transport underneath.

Deleted:
- AkkaCentralTransport, AkkaSiteTransport (+ their dedicated tests)
- ISiteClientFactory + DefaultSiteClientFactory; CentralCommunicationActor legacy
  ctor + SelectTransport (Host now builds GrpcSiteTransport and injects it)
- ClusterClient creation + both ClusterClientReceptionist.RegisterService calls in
  AkkaHostedService; the RegisterCentralClient message + receive block
- CommunicationOptions.CentralContactPoints; the CentralTransport/SiteTransport
  coexistence flags; the CentralTransportMode/SiteTransportKind enums

gRPC is now the only site↔central transport (site→central CentralControlService via
GrpcCentralTransport; central→site SiteCommandService via GrpcSiteTransport), both
built unconditionally by the Host. NoOpCentralTransport is the fail-loud null-default
so TestKit command-dispatch suites still construct the site actor without a wired
transport; production always injects GrpcCentralTransport.

Config: CentralGrpcEndpoints is now unconditional — CommunicationOptionsValidator
rejects blank entries (role-agnostic), and StartupValidator requires a Site node to
list >=1 endpoint (fail-fast, mirrors GrpcPsk). Rig configs moved
CentralContactPoints -> CentralGrpcEndpoints (docker x6, docker-env2 x2, Host default,
deploy/wonder-app-vd03). Kept Akka.Cluster.Tools (ClusterSingleton still used).

Tests: build 0/0; Communication.Tests 640, Host.Tests 421 green. Removed the
ClusterClient.Send per-site-routing tests (covered by the transport suites), swapped
the ISiteClientFactory-based ctors to a substitute ISiteCommandTransport, converted
the audit-push integration relay to an in-process bridge transport.

Docs: Component-Communication/Host/StoreAndForward, components/Communication,
topology-guide, grpc_streams (SUPERSEDED note), the frame-size known-issue (retired
amendment), and CLAUDE.md transport decisions.

Not included: the dead IntegrationCallRequest path (#32) is a separate user-owned
behavioral decision — SiteEnvelope routing is transport-agnostic so it still compiles.

docs/known-issues/2026-06-26-deploy-config-exceeds-akka-frame-size.md

@@ -31,6 +31,25 @@ Any deployment replicating wide rows must size that key deliberately; see the Ph
 Note the failure mode differs from the one documented below: an oversized gRPC message is
 **rejected**, not silently dropped.
 
+## Amendment (2026-07-23) — Akka frame-size class RETIRED for site↔central command/control
+
+Phase 4 of the ClusterClient→gRPC migration deleted the Akka `ClusterClient` site↔central transport
+entirely. **All site↔central command/control now rides gRPC** — central→site over `SiteCommandService`
+(`GrpcSiteTransport`) and site→central over `CentralControlService` (`GrpcCentralTransport`), each with
+the gRPC default 4 MB message cap and **no per-message Akka frame limit**. Consequently:
+
+- The 128 KB Akka `maximum-frame-size` constraint **no longer applies to any site↔central command
+  message**, including `DeployArtifactsCommand`, which still carries its payload inline but now travels
+  over gRPC.
+- The **silent frame-drop failure mode** described below — the transport dropping one oversized message
+  while heartbeats keep flowing and the deploy hangs to its timeout — **cannot occur on that path any
+  more.** An over-cap gRPC message is *rejected* with an error, not silently discarded.
+- The notify-and-fetch deploy path (the 2026-06-26 resolution) still stands and remains the deploy
+  mechanism; it is simply no longer the *only* thing keeping large payloads off a frame-limited hop.
+- Akka remoting is now intra-cluster only, so its frame size governs only pair-internal traffic.
+
+See `docs/plans/2026-07-22-clusterclient-to-grpc-plan.md`.
+
 The diagnosis below is retained as the historical record of how the bug was found and reasoned about.
 
 ## Summary