issue-3653 A8 option B: tier selection falls back to a coarser trustworthy tier

[erikdarlingdata]

Part of #3653

What changed

BaselineMath.SelectBucket picked a tier (Full → HourOnly → Flat) purely by
sample count, then handed the chosen bucket back even when
BaselineBucket.IsTrustworthy was false for it. At a 5-minute collection
cadence, the Full (hour+dow) tier clears its sample floor (10-14 samples) on
day one, but Full's day floor is 3 DISTINCT same-weekday dates — one per
calendar week — so it stayed selected-but-untrustworthy for about three
weeks on a newly monitored target, even though the coarser HourOnly tier
(day floor 10, ~10 days) or Flat tier (day floor 3, ~3 days) was already
trustworthy. Every z-score detector was routed to the much higher
absolute-threshold bar for that whole window.

SelectBucket now:

1. Computes today's choice by sample count exactly as before (chosen).
2. Returns chosen unchanged if it IsTrustworthy OR IsZeroHistory — mature
   targets are byte-identical, and the zero-history arm (A month of zeros is the strongest baseline there is, not the absence of one: a zero-history bucket now fires as an extremity instead of routing to the young-store fallback bar (#3691) #3849, measured by
   PostgreSQL-target analysis engine: v2/v3 slices and the v1 lanes' residue (from #3542) #3691 D8) is never overridden.
3. Otherwise walks only the tiers COARSER than chosen (HourOnly then Flat),
   building each exactly as today (the provider's exact GROUPING SETS
   sentinel when present, else pooled synthesis, gated by the same
   CollapseThreshold/3 sample floors), and returns the first one that IS
   trustworthy.
4. If none is, returns the original chosen, unchanged — today's
   absolute-fallback path and low-quality metadata.

All three consumers (PgBaselineProvider.LookUp, Lite BaselineProvider,
BaselineBucketMap.For) go through SelectBucket, so this one change
covers every surface. Thresholds, tier floors, IsTrustworthy and every
caller are unchanged.

Touched only BaselineMath.cs and RobustBaselineTests.cs, per brief.

Tests added (Darling/Darling.Tests/RobustBaselineTests.cs)

• SelectBucket_ChosenFullUntrustworthy_ExactHourOnlyTrustworthy_ReturnsHourOnly
• SelectBucket_FullAndHourOnlyUntrustworthy_ExactFlatTrustworthy_ReturnsFlat
• SelectBucket_EveryTierUntrustworthy_ReturnsChosenFull_TheAbsoluteFallbackAsToday
• SelectBucket_ChosenFullIsZeroHistory_NeverReplacedByACoarserTier
• SelectBucket_TrustworthyFull_ReturnedUnchanged_MatureTargetIsByteIdentical
• SelectBucket_NoSentinels_PooledFullUntrustworthy_PooledHourOnlyTrustworthy_ReturnsPooledHourOnly

All pre-existing SelectBucket tests are unchanged and still pass — none of
their fixtures fell in the 3–20-day young-target band this lane targets.

A doc-comment collision: DocCommentHygieneTests.NoMemberCarriesTwoStackedSummaryBlocks
caught two stacked <summary> blocks I'd left on SelectBucket (the new
rationale as a second <summary> instead of another <para> in the
existing one). Fixed by merging it in as a <para>, verified green in a
follow-up commit (4195e82).

What I ran

• dotnet build on PerformanceMonitor.Analysis, Darling/Darling.Tests,
  Lite/PerformanceMonitorLite.csproj, Lite.Tests/Lite.Tests.csproj with
  -p:EnableWindowsTargeting=true — all green, 0 warnings, 0 errors, after
  the doc-comment fix.
• Targeted classes on a live TimescaleDB rig (timescale/timescaledb:2.28.1-pg18,
  DARLING_TEST_PG set): RobustBaselineTests (35), LocalClockBucketKeyTests
  (13), AnomalyGateNullWindowMonteCarloTests (11), AnomalyGateTilesTests
  (17), PgTargetAnomalyTests (44), DarlingAnomalyBaselineTests (18),
  DarlingAnalysisStoreTests (9), DarlingAnalysisBudgetTests (3),
  DarlingAnalysisServiceEngineRoutingTests (11),
  DarlingAnalysisPipelineTests (11) — all green, 0 failed, 0 skipped.
• AnomalyNullWindowLiveTests (still [Fact(Explicit = true)], HistoryDays = 10), run with -explicit on -showLiveOutput on both origin/dev and this
  branch against the same live rig:
  • dev: DIAG shiftFires4h=0 shiftPasses4h=3 shiftFires24h=0 shiftPasses24h=3 spikeAlone4h=0 spikeAlone24h=0 null4h=0/57 null24h=0/12
  • this branch: identical DIAG line, byte for byte.
    Honest read: no change at 10 days of history for this particular fixture's
    pattern — its z-path outcome here isn't gated by tier trust in the way that
    moved. I'm reporting the DIAG lines as instructed rather than reading a
    result into them.
• Full Darling suite once, DARLING_TEST_PG unset:
  Total: 13671, Errors: 0, Failed: 214, Skipped: 730, Not Run: 2. Diffed
  the failing-test names byte for byte against the same run on origin/dev
  (Total: 13665, Failed: 214) — identical failing-test set, all
  pre-existing WPF/Windows-only tests that don't run on this Mac. This
  branch adds 6 new tests (the ones above) with zero new failures and zero
  regressions.
• Lite/PerformanceMonitorLite.csproj and Lite.Tests/Lite.Tests.csproj
  built clean with -p:EnableWindowsTargeting=true. Did not run
  Lite.Tests (hangs on this Mac per brief); left to CI.

Watch in CI (Lite.Tests, 3–20 day seeded-history fixtures asserting the absolute path)

• AnomalyDetectorTests.DetectCpuAnomalies_ThinBaseline_AbsoluteFallbackFires_NotSilent
  and AnomalyDetectorTests.DetectCpuAnomalies_ThinBaseline_SuppressesPureZSpikeBelowAbsoluteBar
  — both use SeedThinBaselineCpu (2 distinct days, 16 samples). By this
  lane's rule this Full bucket is untrustworthy, and there's no HourOnly or
  Flat sentinel/pooled data seeded in that fixture, so both stay on the
  absolute-fallback path exactly as asserted. Flagging anyway since they're
  exactly the shape this lane changes behavior for.
• AnomalyDetectorTests also has SeedThinBaselineWaitRates (2 distinct
  days) feeding wait-rate anomaly tests — same reasoning, same expected
  outcome (no seeded coarser tier to fall back to, so unchanged).
• ComparisonBandingTests.AnUntrustworthyBaseline_FallsBackToTheAbsoluteRule
  constructs a single untrustworthy BaselineBucket directly (not through
  SelectBucket/a map) and asserts on ComparisonBanding, not on tier
  selection — unaffected by this change, but flagging since it lives in the
  same 1-distinct-day territory.
• I did not find any Lite.Tests fixture with 3–20 days of history where a
  coarser sentinel/pooled tier IS present and trustworthy, so I did not
  expect (and did not find, by build) any Lite.Tests compile-time
  expectation change.

Not verified

• Live behavior against a real newly-onboarded target end to end (only unit-
  level SelectBucket fixtures and the one AnomalyNullWindowLiveTests
  demonstration, which showed no delta at 10 days for its specific fixture).
• Lite.Tests actual pass/fail (build-only on this Mac; CI runs it).

CHANGELOG entry

On a newly monitored server, anomaly detectors use the hour-of-day or overall baseline while the hour-of-week one is still too young to trust, instead of only the absolute threshold. Anomaly detection now starts in days rather than about three weeks (#3653).

[erikdarlingdata]

Lane L1e-2 done. Narrowed the tier walk to YOUNG buckets only, per the ruling.

Changes (91a978e, 9403808 on feat/3653-b-trusted-tier):

• BaselineBucket.cs: added IsYoung — EffectiveStdDev > 0 && SampleCount >= sampleMin && DistinctDays < dayMin — true only for the untrustworthy-for-too-few-distinct-days case, never for a trustworthy, zero-dispersion, or thin bucket.
• BaselineMath.SelectBucket: replaced if (chosen.IsTrustworthy || chosen.IsZeroHistory) return chosen; with if (!chosen.IsYoung) return chosen;. Doc comment updated to explain why the old !IsTrustworthy gate over-walked.
• RobustBaselineTests.cs: added (g) a zero-dispersion Full bucket with a trustworthy coarser tier present — not walked, returns Full; and (h) a boundary test — since CollapseThreshold (10) equals Full's own trust sample floor, a genuinely sub-floor-sample Full bucket is never selected as Full in the first place (falls through to HourOnly/Flat in SelectBucketBySampleCount), so a literal "thin Full bucket in the 10-14 hysteresis band" per the brief's (h) isn't reachable from the chosen-Full arm. Pinned the boundary instead: a Full bucket sitting exactly at the sample floor with too few distinct days is walked on DAYS alone.
• Gave the 3 CI-failing Lite fixtures (BaselineProviderTests.GetBaseline_SparseBucket_CollapsesToHourOnly, BaselineProviderTests.GetBaseline_HourOnly_SumsDistinctDaysAcrossDowBuckets, LocalClockBucketKeyTests.Provider_ZoneId_EstAndEdtRowsAcrossTheSpringForward_ShareOneLocalBucket) enough distinct days to clear their tier's own floor — all three were IsYoung under the narrowed rule (by design), so the fix was giving them more days, not flipping the expected tier.

Verified: Darling build (-p:EnableWindowsTargeting=true) green. Targeted runs green: RobustBaselineTests 37/37, all *Baseline* classes, AnomalyGateTilesTests 17/17, AnomalyGateNullWindowMonteCarloTests 11/11 — no [FAIL]. Lite.Tests builds clean; execution left to CI per policy (WPF host hangs on this Mac). Round-1 CI run 36044101657 failed on exactly the 3 named Lite tests plus a live PG DST test unrelated to this fix (pre-existing on this branch, not touched). Round-2 CI (this push) not yet observed by me — handing to pr-tender to poll and confirm green within the 2-round budget.

Not verified: full Darling suite with DARLING_TEST_PG unset (214 baseline) — ran out of budget window; targeted classes above cover the touched surface. No live PG rig was started for this lane.