On-load collectors band on the same staleness ladder as any other collector (#4000)

[erikdarlingdata]

Closes #4000.

Why

CollectorHealthClassifier.Classify (PerformanceMonitor.Common/ServerHealthBands.cs) permanently
exempted an on-load collector (server_config, database_config, database_scoped_config,
trace_flags, server_properties) from every staleness band, reading it by failure/abandon rate
alone. That was correct when an on-load collector's only capture was the last connect. Since
#3929/#3930 gave every one of them a real daily reschedule (CollectorScheduleDefaults.OnLoadRecaptureMinutes
= 1440) on top of the connect-time capture, "hours since last success" became a meaningful signal
again - but the exemption stayed, so a daily reschedule that silently breaks (a bug in the NextDue
seeding, an exception swallowed before the run) whose historical runs were all successes still read
HEALTHY forever. That is the exact blind spot that let #3930's field defect go unnoticed.

Erik's ruling (posted on the issue): no new thresholds or settings. Classify on-load collectors like
any scheduled collector, on the effective 1440-minute cadence
(CollectorScheduleDefaults.EffectiveRecurringIntervalMinutes), with the existing staleness bands.

What changes

• CollectorHealthClassifier.Classify - removed the isOnLoad parameter and the exemption branch
  entirely. The method is now a pure function of run counts and cadence; on-load-ness is no longer a
  distinct input, only a distinct CADENCE the caller resolves before calling in. Parameter count: 10 -> 9.
• Three FrequencyMinutes properties (one per surface) now route the catalog lookup through
  CollectorScheduleDefaults.EffectiveRecurringIntervalMinutes, so a 0 default (on-load, or a
  collector no longer in the catalog) resolves to the 1440-minute daily cadence instead of the 24h/4h
  floors a raw 0 used to fall to:
  • Lite/Services/LocalDataService.CollectionHealth.cs (CollectorHealthRow)
  • Darling/PerformanceMonitor.Darling.Viewer/ViewerDataService.CollectionHealth.cs (CollectorHealthRow)
  • Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingDataReader.cs (CollectorHealth)
• Fleet rollup covered for free: DarlingFleetReader.cs constructs the SAME CollectorHealth type
  from FleetCollectionHealthSql's rows, so the fix reaches the fleet overview without a separate change.
  Confirmed by reading DarlingFleetReader.cs - no direct Classify call there to update.
• IsOnLoadCollector/OnLoadCollectorNames stay - still consumed by ProducedThenStopped's "three
  tab opens are not three consecutive cycles" exclusion, which is a different concept (consecutive-run
  semantics, not staleness) and out of this issue's scope.
• Doc comments updated everywhere the old exemption was described as permanent (the IsOnLoadCollector
  summary, Classify's order-of-bands summary, and one stale cross-reference in FormatOutputFinding's
  remarks that cited Classify's isOnLoad pattern by name).

Test plan

• Darling.Tests and Lite.Tests both build with 0 Warning(s).
• Decision-table pins (Classify_BandsTheDecisionTable, both SKUs) updated: isOnLoad column
  removed from every row; the old "on-load exemption" demonstration rows (500h dark -> Healthy/Warning)
  now assert the corrected Stopped outcome instead of being deleted, so the removed behavior stays
  pinned as a regression rather than silently disappearing.
• New regression coverage, both SKUs, mirroring the existing index_object_stats boundary facts
  but through a REAL on-load collector name (server_config) so the catalog resolution
  (EffectiveRecurringIntervalMinutes) and the ladder are exercised together, not just the pure
  Classify function:
  - 27h since last success -> HEALTHY (well inside the new 36h stale line)
  - 37h -> STALE (was HEALTHY forever before this fix)
  - 49h -> STOPPED (was HEALTHY forever before this fix - the A Darling server connected for more than 30 days loses its config facts: on-load snapshots age out and nothing re-collects them #3930-shaped blind spot)
  - Darling additionally checks both CollectorHealthRow (viewer) and CollectorHealth (MCP
  service) at 49h in one fact, matching the suite's existing "on both row types" discipline.
• Pin tests caught and fixed deliberately, not weakened: TheBandingSignature_TakesNoOutputAndNoDenialCurrency
  (CollectionOutputBesideCostTests.cs, both SKUs) reflects Classify's exact parameter list by
  name/count - updated from 10 to 9 parameters with the reason (On-load collectors are now staleness-exempt forever in CollectorHealthClassifier, even though they recapture daily #4000 removed isOnLoad) in the
  comment, per this repo's "update a pin deliberately, never weaken one" rule.
• Targeted class runs, both executables (-class per touched class, not by file - some of these
  files hold exactly one class each, verified by grep before running):
  - Darling.Tests: CollectorHealthClassifierTests 72/72, {RegressedFromProductiveTests, ProductiveZeroBandingTests, AbandonedRunEraInvariantReadTests, CollectionOutputBesideCostTests}
  49/49 (1 skipped, pre-existing/unrelated), DocCommentHygiene* 77/77 (doc comment edits didn't
  trip the hygiene pin).
  - Lite.Tests: {CollectorHealthClassifierTests, RegressedFromProductiveTests, CollectionOutputBesideCostTests} 90/90.
  - All: 0 failed.
• Full suite NOT run locally (Darling.Tests.exe / Lite.Tests.exe with no filter) - flagging
  for the coordinator rather than silently skipping: this lane hit a hard 13:10Z deadline shared
  with a second issue (MCP get_trace_flags and the web viewer share a narrower version of #3929's stale-flag defect #3999) on its own branch, and every class touched by this diff (by grep,
  not by filename) is covered above. CI will run the full suite on this PR; please treat that as
  the gate before arming auto-merge rather than assuming my local run covered it.

What the coordinator should double-check

• The parameter-count pin change (10 -> 9) in CollectionOutputBesideCostTests.cs is a deliberate,
  reasoned update (see comment), not a weakening - it now asserts a SMALLER number, which a careless
  "make the test pass" edit could get backwards (e.g. by leaving 10 and hoping for a compile error
  instead of a runtime pin failure). Worth a second look.
• Lite parity: confirmed by reading Lite/Services/LocalDataService.CollectionHealth.cs alongside both
  Darling surfaces - all three FrequencyMinutes properties had byte-for-byte identical logic before
  this change and now have byte-for-byte identical fixes.
• No store migration - this is pure C# classifier/read logic, no schema change.
• CI's full-suite run is the one gate this PR has not seen locally (see Test plan above).

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv

[erikdarlingdata]

Coordinator fixes (d60435d), after CI failed 4 tests the lane never ran:

• Product fix: FrequencyMinutes (Darling MCP, Darling viewer, Lite) had mapped every name missing from the catalog to the daily cadence too, so a collector 30 h dark read HEALTHY instead of STOPPED. That was the live seven-day aggregate failure. Only a catalog on-load entry resolves to 1440 now. Unknown names keep the floor ladder, as before On-load collectors are now staleness-exempt forever in CollectorHealthClassifier, even though they recapture daily #4000, pinned by a new fact.
• Tests aligned to the ruling:
  • the Classify signature pin is 9;
  • an on-load collector is HEALTHY at 2 h and STOPPED at 100 h;
  • the failure-rate WARNING is asserted with a recent success.
• Targeted Darling classes 140/140 live (PG 18.6 + TimescaleDB 2.30.1); full Lite suite 5179/5179.