refactor(fleet): #542 delete the dead fleet-status chain (broadcaster, SignalR bridge, hub, messages)

#542 filed FleetStatusBroadcaster as blind to site nodes since the Phase 6 per-cluster mesh
split: it derives "the fleet" from central's own Akka gossip ring, which after the split is
just central's own pair. Scoping the cross-mesh rewrite found the deeper truth — the whole
chain is dead end to end, so this deletes it rather than reviving it.

  - Zero consumers. FleetStatusBroadcaster published FleetStatusChanged on the DPS
    "fleet-status" topic; FleetStatusSignalRBridge forwarded it to FleetStatusHub
    ("/hubs/fleet-status"); nothing anywhere connected. The AdminUI bans self-connecting
    HubConnections, no browser JS subscribes, and /fleet (Fleet.razor) reads
    NodeDeploymentState from the ConfigDb plus IClusterRoleInfo on a 5 s poll instead.
  - Its second input never existed. DriverHostStatusHeartbeat had no production sender —
    only the broadcaster's own test told it — so CurrentRevision was always null and the
    30 s staleness -> Degraded flip could never fire.
  - Post-Phase-6 DPS is pair-local, so even the central-only view it did produce was an
    accident of topology rather than a design.

The fleet visibility that actually works is unchanged and already cross-mesh-correct:
/fleet over NodeDeploymentState, and the four Phase 5 per-node telemetry dials.

Precedent for deleting inert machinery rather than activating it: #522 (driver stability
tiers), #507 (discovered-node injection), #525 (GetMemoryFootprint).

Deleted: FleetStatusBroadcaster (+ its nested DriverHostStatusHeartbeat), its admin
singleton registration and FleetStatusBroadcasterKey, FleetStatusSignalRBridge and its
key, FleetStatusHub and its route mapping, and the FleetStatusChanged / FleetNodeStatus /
FleetNodeHealth messages. Both Fleet/ directories survive — ControlPlane keeps
ClusterNodeAddressReconciler, Commons keeps GetDiagnostics. Docs swept where they claimed
a fleet-status channel exists (Telemetry.md's Phase 5 non-migrated channels,
Configuration.md, CLAUDE.md); completed-program plan docs under docs/plans and docs/v2 are
left as the historical record they are.

Build 0 errors, 868 warnings — byte-identical to master's rebuild baseline.
ControlPlane.Tests 231/231, AdminUI.Tests 1109/1109.

Claude-Session: https://claude.ai/code/session_014WNM4vjoVksyyBraTXSZE1

docs/Configuration.md

@@ -273,11 +273,12 @@ discipline as `MeshTransport:Mode` and `ConfigSource:Mode`.
 otherwise) — enforced by `TelemetryOptionsValidator`. **`Grpc` mode on either side requires a
 non-empty `ApiKey`** — fail-closed, same as `ConfigServe`/`LocalDb:Replication`.
 
-**Three DPS observability topics stay out of scope for this transport, on purpose:**
+**Two DPS observability topics stay out of scope for this transport, on purpose:**
 `redundancy-state` (pair-local, built from `Cluster.State`, stays on DPS in both modes — see
-[`Redundancy.md`](Redundancy.md#command-transport-centralnode)), `fleet-status` (central-internal;
-`Fleet.razor` polls the Config DB, not any stream), and `deployment-acks` (already rides the Phase 2
-gRPC command transport, `CentralCommandService.ReportApply`, as a command-plane reply). See
+[`Redundancy.md`](Redundancy.md#command-transport-centralnode)) and `deployment-acks` (already rides
+the Phase 2 gRPC command transport, `CentralCommandService.ReportApply`, as a command-plane reply).
+A third, `fleet-status`, was **deleted** rather than deferred (2026-08-06, Gitea #542 — it had no
+client end to end; `Fleet.razor` polls the Config DB). See
 [`docs/Telemetry.md`](Telemetry.md) for the full architecture, the reconnect/generation-stamped
 dialer story, and the rationale for the node-hosts/central-dials inversion.