Merge fix/issue-542-fleetstatus: delete the dead fleet-status chain (#542)

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

docs/Configuration.md

@@ -275,11 +275,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.
 

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.