On-load config collectors also recapture daily, not just on connect (#3929) (#3930)

[erikdarlingdata]

Closes #3929. Closes #3930.

Why

Five config collectors (server_config, database_config, database_scoped_config, trace_flags,
server_properties) run once per connect (FrequencyMinutes 0 in CollectorScheduleDefaults) and never
again while the connection stays healthy.

• A Darling server connected for more than 30 days loses its config facts: on-load snapshots age out and nothing re-collects them #3930: a server connected for more than 30 days loses its only capture to the 30-day retention purge, so
  CONFIG_*, DB_CONFIG, TRACE_FLAGS and the config audit have nothing to read until the next reconnect.
• TRACE_FLAGS keeps reporting a trace flag for weeks after it is turned off #3929: TRACE_FLAGS partitioned each trace flag's latest row across all retained history with no time
  bound. DBCC TRACESTATUS(-1) only ever lists flags that are ON, so a flag turned off never got another row
  to supersede its stale ON one - it kept reporting as enabled for up to 30 days after being turned off.

Erik ruled (both issues, 2026-09-23): re-capture the on-load collectors daily, in addition to on connect. That
fixes both.

What changes

• CollectorScheduleDefaults.OnLoadRecaptureMinutes (1440) and EffectiveRecurringIntervalMinutes are the one
  place "on-load" (frequency 0) becomes a concrete periodic interval. Darling's worker (the connect-time seed,
  the reload recompute, and the due-collector sweep - three call sites that all previously treated frequency 0
  as "never schedule again") and Lite's ScheduleManager.GetDueCollectorsForServer both call it instead of
  special-casing the five on-load collectors by name. An operator's own override (any frequency > 0) is
  untouched, since the substitution only fires when the EFFECTIVE (post-override) frequency resolves to 0.
• The on-connect capture is unchanged in both SKUs (Darling's TryConnectAsync on-load loop; Lite's
  RunAllCollectorsForServerAsync tab-open path, which already runs every enabled collector unconditionally).
• TRACE_FLAGS's read (Darling PgFactCollector.Config.TraceFlagsSql, Lite DuckDbFactCollector.Config) is
  now bounded by capture_time BETWEEN $2 AND $3 - the on-load-aware lookback (a day, or twice
  OnLoadRecaptureMinutes if longer; 48h at the shipped daily default) and the window's end, matching every
  other latest-value read (Analysis 'latest value' reads scan a server's entire retained history: half of every analyze_server call, and the database-size fact counts dropped databases (all three SKUs) #3896/Latest-value lookbacks follow the collector's cadence: a day, or twice its interval if longer (#3896) #3980). A flag missing from the whole window (about two daily captures) has
  no row there at all and simply drops out - including the "every flag is off" case, where the OLD
  MAX(capture_time) anchor Analysis 'latest value' reads scan a server's entire retained history: half of every analyze_server call, and the database-size fact counts dropped databases (all three SKUs) #3896 used for DB_CONFIG would have silently fallen back to an older, stale-ON
  capture (a capture that finds nothing on writes zero rows, so MAX never sees it).
  server_config/database_config/server_properties needed no read change: their existing "newest capture"
  anchors are already correct once that capture is at most a day old, which the scheduling half of this PR
  guarantees.
• Filed two follow-ups instead of folding them in (real but out of lane - see below): MCP get_trace_flags and the web viewer share a narrower version of #3929's stale-flag defect #3999 (a narrower version
  of TRACE_FLAGS keeps reporting a trace flag for weeks after it is turned off #3929's defect in the MCP get_trace_flags tool and the web viewer) and On-load collectors are now staleness-exempt forever in CollectorHealthClassifier, even though they recapture daily #4000 (the health classifier's
  permanent on-load staleness exemption, now a blind spot since these collectors have a real cadence).

Test plan

• New regression tests proven to fail on the pre-fix shape: reverted TraceFlagsSql's bound (Darling) and
  reverted GetDueCollectorsForServer's substitution (Lite) one at a time, confirmed the new tests fail (3
  Darling, 3 Lite), restored the fix, confirmed green.
• Darling.Tests targeted, against a private rig (PostgreSQL 18.6 + TimescaleDB 2.30.1): LatestValueLookback*
  (56, incl. 3 new), StoreConfigProviderTests (14, incl. 3 new), CollectorHealthClassifierTests,
  SweepPressureClassifierTests, DarlingSweepSchedulingTests, PgFactCollectorTests, StartupCommandTimeoutTests,
  AlertReadFailureSurfaceTests, DocCommentHygiene (248 total across that second batch) - all green.
• Lite.Tests targeted: LatestValueLookbackTests (10), OnLoadRecaptureScheduleTests (6, new),
  DeltaFamilyScheduleBoundTests, CollectorHealthClassifierTests, SweepPressureClassifierTests,
  SharedCollectorDefaultsPinTests, CrossAppPresetValuePinTests, ConfigCollectorsDefinitionTests, ParitySource
  (89 total across that batch) - all green.
• Full Lite.Tests suite once: 5160 total, 1 failure. The failure (StatusBarSizeReadLockTests, an
  unrelated write-lock-contention timing test) re-ran green alone - a pre-existing flake, not touched by this
  PR.
• Full Darling.Tests suite once, against the same private rig: 12,941 total, 0 failures, 27 skipped (all
  gated on runtime/role-provisioning env vars this PR does not touch - DARLING_TEST_PGRUNTIME and friends).

Filed separately (parked, not in this PR)

• MCP get_trace_flags and the web viewer share a narrower version of #3929's stale-flag defect #3999: the MCP get_trace_flags tool and the web viewer's trace-flags read share a narrower version of
  TRACE_FLAGS keeps reporting a trace flag for weeks after it is turned off #3929's defect (MAX(capture_time) silently falls back to a stale capture when the newest one found zero
  flags on). Real but distinct from the analysis-fact defect this PR fixes, and touches display-surface files
  this PR doesn't otherwise change.
• On-load collectors are now staleness-exempt forever in CollectorHealthClassifier, even though they recapture daily #4000: CollectorHealthClassifier.Classify still exempts on-load collectors from staleness bands forever.
  Now that they recapture daily, a genuinely-stuck on-load collector could be flagged like any other daily
  one - but that needs a threshold ruling and touches SQL call sites across the fleet rollup and per-server
  health reads this PR doesn't otherwise touch.

Follow-up commit (coordinator)

• TRACE_FLAGS reads the window's newest capture instead of each flag's newest row inside the window. A flag turned off while another stays on now drops out at the next daily capture instead of lingering up to two days. The all-flags-off case (a capture that writes no row) still falls back to the previous capture, bounded by the window. Both SKUs.
• New tests: a live Darling test and a Lite unit test (flag on yesterday with another, gone this morning) that fail on the per-flag shape. Targeted runs: Darling 122/122 live, Lite 79/79 and then 9/9.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv