Overview reads collection-health rollup instead of scanning raw data every 30 s (#4226)

[erikdarlingdata]

Closes #4226.

Regression fixed

ViewerW2aLivePostgresTests.ServerSummary_ReadsEnrichedThreadsMemoryBlockingCollectors_AgainstDevPostgres failed
at Darling/Darling.Tests/ViewerW2aTests.cs:1008 (HealthyCollectorCount expected 1, got 0). Dev's CI passes
this test, so this PR broke it.

Cause

FleetCollectionHealthByServerSql is the new shared read. The Overview cards, the status bar and the
server-tab badge all now call it through GetFleetCollectionHealthByServerAsync. It scoped its rows to
server_id IN (SELECT server_id FROM config_monitored_servers WHERE is_enabled). That scope was copied from
FleetCollectionHealthSql, the viewer's older, unrelated fleet-cumulative total.

The two statements do not share the same scope. Every caller of the new by-server read looks up one server's own
rows. The old raw per-server scans it replaced (CollectionHealthSql, PermissionDeniedCollectorCountSql)
never filtered by enable state. They read by server_id alone.

The test's EnrichServerId is a synthetic id with no config_monitored_servers row at all, so the is_enabled
subquery dropped it entirely. That is also a real production gap, not just a test artifact. Two cases hit it. One: a disabled server whose card, badge and tab need its last 7-day history. Two: the
bootstrap window, where config_monitored_servers is empty before the config store is seeded.

Both were confirmed by running PgMigrations.MigrateAsync alone on a fresh rig database.
collect.collection_health_hourly does not exist yet, so the raw fallback runs, not the composed read.
config.config_monitored_servers has 0 rows, so the is_enabled scope drops every server, not just the
test's synthetic one.

The right precedent was sitting right next to the moved code. The service's own by-server fleet read
(DarlingFleetReader.FleetCollectionHealthSql, now CollectionHealthRollupSupport's twin) scopes to
server_id <> 0 only. The continuous aggregate it composes with (CreateCollectionHealthHourlySql) does the
same. The service's own consumer (GetFleetOverviewAsync) reads the by-server dictionary unscoped, and lets its
own caller decide which server ids to keep. This fix adopts that same pattern for the viewer.

Fix

• FleetCollectionHealthByServerSql now scopes to server_id <> 0 only, matching the CAGG and the service's
  read exactly. Overview cards and the badge key their lookup by one server_id. A per-server status-bar tab
  does too. Each now gets that server's real rows regardless of enable or registration state, matching the old
  raw scans exactly.
• The status bar's fleet-cumulative branch (no tab selected) is the one place that still wants enabled servers
  only. That is the old FleetCollectionHealthSql behavior, where a removed server's aged-out rows must not
  read as erroring. The filter now lives in UpdateCollectorHealthTextAsync itself, against the fleet list
  already in memory (_fleet.All.Where(s => s.IsEnabled)). It no longer lives inside the shared SQL every
  other caller also paid for.
• Updated FleetCollectionHealthByServerSql's doc comment and the OverviewCollectionHealthRollupRoutingTests
  pin (renamed, re-asserted on server_id <> 0) to state the corrected scope and why.
• Added a disabled-server case and an unregistered-server case to
  FleetCollectionHealthByServerLiveEqualityTests. The composed and raw fleet-by-server reads are now checked
  against the old raw per-server scans for both, alongside the existing three enabled servers.

Lite was checked for the same class of bug. Its only change in this PR memoizes its own existing per-server
GetPermissionDeniedCollectorCountAsync scan. That scan was never is_enabled-scoped. Lite has no fleet-wide
read to share. No parity fix was needed there.

What changed

• Darling/PerformanceMonitor.Darling.Viewer/ViewerDataService.CollectionHealth.cs: FleetCollectionHealthByServerSql
  scoped to server_id <> 0, doc comment corrected.
• Darling/PerformanceMonitor.Darling.Viewer/MainWindow.ServerManagement.cs: the status bar's fleet-cumulative
  branch now filters to enabled servers itself.
• Darling/Darling.Tests/OverviewCollectionHealthRollupRoutingTests.cs: pin renamed and re-targeted at the
  corrected scope.
• Darling/Darling.Tests/FleetCollectionHealthByServerLiveEqualityTests.cs: added a disabled-server and an
  unregistered-server case.

Test plan

• ServerSummary_ReadsEnrichedThreadsMemoryBlockingCollectors_AgainstDevPostgres alone: failed before the
  fix (HealthyCollectorCount 0, expected 1), passes after.
• FleetCollectionHealthByServerLiveEqualityTests, OverviewCollectionHealthRollupRoutingTests,
  CollectionHealthAggregateTests: 18/18 passed, including the two new regression cases.
• Every class in ViewerW2aTests.cs (ViewerOverviewSqlTests, ViewerServerSummaryDisplayTests,
  ViewerAlertHistoryW2aSqlTests, ViewerW2aLivePostgresTests) plus FreshStoreWatermarkTests: 84/84 passed.
• Lite's PermissionDeniedBadgeMemoTests: 2/2 passed.
• Census and pin gates (McpPayloadContractCensusTests, StartupCommandTimeoutTests,
  StorageCommandTimeoutTests, AlertReadFailureSurfaceTests, DocCommentHygiene,
  LivePostgresCollectionHygieneTests, LiveCleanupConversionRatchetTests, ReadmeDerivedCountPinTests):
  154 + 5 passed.
• Merged origin/dev (clean, no conflicts) and ran the full Darling.Tests suite once against a freshly
  dropped and recreated darlingtest. Result: 13811 total, 1 failed, 47 skipped, 1 not run, 599s.
  The one failure was ForcePlanFailuresAccessPathTests.TheShippedRead_PlansAsAnIndexOnlyScanOnTheCoveringIndex_AgainstDevPostgres.
  It is an unrelated query-store-stats planner-shape test with zero references to collection health in its
  file. It passed when re-run alone right after. It is full-suite-only, not caused by this diff. It did not
  reproduce in isolation to file cleanly. It is worth a census if it recurs.

CHANGELOG entry

SECTION: Fixed
ENTRY:
- **Collection health by server: fixed scope so disabled and unregistered servers show their history** ([#4236]). `FleetCollectionHealthByServerSql` filtered to enabled servers only. A disabled server showed no collection history at all. A server onboarded before the config store was seeded also showed nothing. The read now scopes to `server_id <> 0` only, matching the service's own read and its CAGG exactly. The enabled-only filter moved to the status bar's fleet-cumulative branch, where it belongs.
REF:
[#4236]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/4236

Generated with Claude Code

https://claude.ai/code/session_01FVjn4PBJN71NQXdFo6ZxNQ