Darling viewer duration trends pick the tier with a second clock read, so a 95-hour window can flip to hourly #5725

Claude posting for Erik Darling.

Which component(s) does this affect?

• Darling

Problem

The Darling viewer's query and procedure duration trends decide the tier (raw or hourly) against a second DateTime.UtcNow read, taken a few milliseconds after the window was computed. ViewerServerTab.QueryTrends.cs calls GetQueryDurationTrendAsync and GetProcedureDurationTrendAsync with no nowUtc, and ReadRoutedDurationTrendAsync falls back to nowUtc ?? DateTime.UtcNow.

A window that starts exactly on the raw boundary (RawRetentionSpan 96 h less RawTierMargin 1 h, so 95 h) can then fall just past it and read the hourly tier instead of raw. PR #5706 fixed the same skew in the MCP tools with DarlingMcpTrendTools.TierClock. The viewer copy was left out, because the viewer receives startUtc and endUtc from its caller and cannot tell whether the end is "now".

Only a window whose start sits within milliseconds of 95 h before now is affected (a custom range), so this is rare.

Proposed fix

Where the viewer builds a live (relative) range, pass the instant it used for the window's end as nowUtc, the way TierClock does with no as_of. For an absolute range, keep the wall clock. Share one definition with TierClock rather than a copy, and pin it with a test at the 95 h boundary.