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/Telemetry.md

@@ -78,7 +78,6 @@ What actually changes per mode, precisely:
     `IDriverStatusSnapshotStore`, `IDriverResilienceStatusStore`).
 - **The AdminUI panels themselves are untouched.** `/alerts`, `/script-log`, and the `/hosts`
   driver table all read from the same sinks in both modes — only the sinks' upstream feed swaps.
-  The `fleet-status` bridge (out of Phase 5 scope — see below) stays on DPS in both modes.
 
 Because hosting is unconditional and both ingest paths are always compiled in, a fleet can be
 flipped node-by-node and central-by-central with no coordination window where telemetry is lost —
@@ -130,10 +129,10 @@ Three things to know before touching it:
 and no reader — the only reference in the repo is its DbSet declaration — while the live data reaches
 the AdminUI over the `driver-resilience-status` channel above. Keep-or-delete is Gitea **#524**.
 
-## The three deferred channels (NOT migrated in Phase 5 — do not read this as "seven done")
+## The three non-migrated channels (NOT migrated in Phase 5 — do not read this as "seven done")
 
 The program sketch originally named seven observability topics for Phase 5. Three were scoped out,
-each for a distinct, settled reason:
+each for a distinct, settled reason — and one of those three has since been deleted outright:
 
 - **`redundancy-state`** — bidirectional, built directly from `Cluster.State`, and **pair-local**:
   it drives ServiceLevel and the Primary data-plane gate, consumed in-process by
@@ -143,11 +142,17 @@ each for a distinct, settled reason:
   in-mesh. Central's *display* of each pair's redundancy state is a Phase 6 cross-mesh concern
   (a future observability channel, once central no longer shares gossip with any site pair), not a
   Phase 5 telemetry-panel migration.
-- **`fleet-status`** — **central-internal**, not a node→central stream at all. The admin singleton
-  `FleetStatusBroadcaster` builds it from the admin node's own cluster membership/reachability/
-  leader events, and `Fleet.razor` **polls the Config DB** and ignores the feed entirely. There is
-  nothing here for a per-node gRPC stream to carry. Revisit in Phase 6, once central genuinely
-  loses gossip visibility of site nodes and needs another way to know a pair's membership.
+- **`fleet-status`** — **DELETED, 2026-08-06, Gitea #542.** There is no `fleet-status` channel any
+  more, on DPS or anywhere else. It was central-internal rather than a node→central stream: the
+  admin singleton `FleetStatusBroadcaster` built it from the admin node's own cluster membership/
+  reachability/leader events and published to a SignalR hub that **no client anywhere ever
+  connected to** — `Fleet.razor` polls `NodeDeploymentState` in the Config DB and always ignored
+  the feed. Its second input, `DriverHostStatusHeartbeat`, had no production sender either. Phase 6
+  then made the central-only view wrong as well (central's gossip ring is its own pair). The whole
+  chain — broadcaster, singleton registration, DPS topic, SignalR bridge, `FleetStatusHub`, and the
+  `FleetStatusChanged`/`FleetNodeStatus` messages — was removed rather than rewritten cross-mesh.
+  Fleet visibility that does work today: `/fleet` over `NodeDeploymentState`, and the four Phase 5
+  telemetry channels above, which are per-node dials and therefore already mesh-independent.
 - **`deployment-acks`** — already migrated, but onto a different transport: it rides the Phase 2
   gRPC command transport (`MeshTransport:Mode=Grpc`, `CentralCommandService.ReportApply`) as a
   command-plane reply, not an observability broadcast. It was never a Phase 5 candidate.