Lite Overview baseline bands use the server's actual hour under a custom range (#4320)

[erikdarlingdata]

Closes #4320.

Why

Lite's Overview tab renders baseline bands (CPU, wait ms/sec, I/O latency, blocking/minute) behind the
correlated timeline lanes. CorrelatedTimelineLanesControl.RefreshAsync computed a referenceTime to key
those baseline lookups and fed it to GetBaselineForLaneAsync -> BaselineProvider.GetBaselineAsync ->
BaselineLocalClock.LocalKey, which expects a UTC DateTime and converts it to the server's local hour and
day-of-week itself.

Under a CUSTOM time range, fromDate is already server-local (ServerTab's pickers convert it before
RefreshOverviewAsync ever sees it — the same fact GetCurrentWindowServerLocal's doc comment records for
the #4296 ghost-line fix). The old code, fromDate ?? DateTime.UtcNow.AddHours(-hoursBack), passed that
server-local value straight through as if it were UTC. LocalKey then converted it to server-local A SECOND
TIME, shifting the baseline lookup by the server's own UTC offset. On a server at UTC+5, a custom range
starting at server-local 09:00 was looked up as if it were UTC 09:00, i.e. server-local 14:00 — a 5-hour
bucket error; on a UTC-7 server the same 09:00 start looked up server-local 02:00, a 7-hour error the other
way. A PRESET range was already correct: DateTime.UtcNow.AddHours(-hoursBack) is genuinely UTC, so no
conversion was needed there.

I confirmed this by reading BaselineLocalClock.LocalKey (PerformanceMonitor.Analysis/Baselines/, ~line
280) and GetBaselineForLaneAsync/BaselineProvider.GetBaselineAsync, and I did not find any other place
that re-corrects the offset before the lookup — the bug is exactly where the issue's correction comment
placed it.

What changes

• Lite/Controls/CorrelatedTimelineLanesControl.xaml.cs: add GetBaselineReferenceTimeUtc(hoursBack, fromDate, utcNow, utcOffsetMinutes), beside the existing GetCurrentWindowServerLocal. Under a custom
  range it converts fromDate back to UTC (fromDate - utcOffsetMinutes); under a preset range it returns
  utcNow.AddHours(-hoursBack) unchanged. RefreshAsync now calls this helper instead of using fromDate
  directly.
• RefreshAsync takes utcOffsetMinutes as an explicit parameter instead of reading
  ServerTimeHelper.UtcOffsetMinutes ambiently — matching the existing pattern on
  GetCurrentWindowServerLocal/GetOverviewComparisonRange, both of which already take utcNow/
  utcOffsetMinutes explicitly so a test can drive them deterministically.
• Lite/Controls/ServerTab.Refresh.cs: the one caller now passes ServerTimeHelper.UtcOffsetMinutes, the
  same value it already passes to GetOverviewComparisonRange on the line above.
• The Dashboard's own copy of this control is out of scope here — PR Dashboard query comparison grids use the server's local time (#4313) #4321 fixes it separately, correctly,
  for its server-local baseline handling.

Test plan

• Lite.Tests.csproj builds with 0 Warning(s), 0 Error(s).
• New pins in Lite.Tests/OverviewComparisonWindowOffsetTests.cs, the existing class for this file:
  • GetBaselineReferenceTimeUtc_CustomRange_ConvertsFromDateBackToUtc (UTC+5 and UTC-7): a custom range's
    result is fromDate - utcOffsetMinutes.
  • GetBaselineReferenceTimeUtc_PresetRange_UsesUtcNowUnchanged (UTC+5 and UTC-7): a preset range's result
    is utcNow - hoursBack, unchanged by the offset.
  • BaselineReferenceTime_UsesHelper_NotFromDateDirectly: a source pin that RefreshAsync calls the new
    helper rather than falling back to a raw fromDate.
  • Proved these fail on the pre-fix code: reverted both production files to this branch's parent commit
    (before either method/parameter existed), which broke the build for the two Theory tests (CS0117,
    the method doesn't exist yet); guarded those two out and reran the source pin alone against the reverted
    source, which failed its Assert.False on the old fromDate ?? DateTime.UtcNow.AddHours(-hoursBack)
    string. Restored both files from HEAD and removed the guard before committing; all 14 tests in the
    class pass again on the fixed code.
• Full Lite.Tests.exe suite, run once after merging origin/dev (which had advanced by three unrelated
  PRs while this branch was in progress — merged clean, no conflicts, confirmed the merge added nothing of
  mine beyond the three files below): 5413 total, 0 errors, 0 failed, 0 skipped, 291.4s.
• No live/manual verification against a real non-UTC server clock was run (none of Lite's rig facilities
  apply here — this is a pure WPF/desktop app fix with no PostgreSQL or SQL Server rig involved).

Diff (git diff --numstat origin/dev...HEAD):

54  0  Lite.Tests/OverviewComparisonWindowOffsetTests.cs
21  3  Lite/Controls/CorrelatedTimelineLanesControl.xaml.cs
1   1  Lite/Controls/ServerTab.Refresh.cs

For the coordinator

• RefreshAsync's new utcOffsetMinutes parameter has exactly one caller in Lite (confirmed by grep across
  Lite/ and Lite.Tests/) — ServerTab.Refresh.cs's RefreshOverviewAsync, updated in this PR. The
  Dashboard's separate, deprecated copy of this control (deprecated/Dashboard/Controls/) is untouched, per
  the brief and PR Dashboard query comparison grids use the server's local time (#4313) #4321.
• origin/dev moved by three unrelated PRs (WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234, Store host visibility: a cross-platform host profile, a --check-settings verb, and a get_store_host read, so "is this store sized right" has an answer without shell access #4214, WPF Active Queries grid reads 24 h of snapshots with full plan XML on every 30 s refresh: 221–499 MB per server, 5–7.7 s per read, ~1 GB of strings, to enable two buttons #4239-related merges) while this branch was being
  built and tested; merged clean with no conflicts, and git diff --numstat origin/dev...HEAD confirms this
  PR's actual content is still only the three files listed above.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Lite Overview baseline bands used the wrong hour under a custom time range on a server not on UTC
  ([Lite Overview baseline bands use the server's actual hour under a custom range (#4320) #4325]) - Under a custom time range, the Overview tab's CPU, wait, I/O latency, and blocking baseline
  bands were keyed off the server-local start time as if it were UTC, shifting the lookup by the server's own
  UTC offset a second time. A preset range was already correct. Custom ranges now convert the start time back
  to UTC before the baseline lookup, on any server not on UTC.
  REF:
  [Lite Overview baseline bands use the server's actual hour under a custom range (#4320) #4325]: Lite Overview baseline bands use the server's actual hour under a custom range (#4320) #4325

🤖 Generated with Claude Code

https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3