DESKTOP: the Queries tab's floor probes skip a range of 90 minutes or less, and the event-grid live tests run the tab's own banner step (part of #4966)

[erikdarlingdata]

Part of #4966.

What changes

1. The Queries tab's three floor probes skip a range of 90 minutes or less.
GetQueryStatsWindowFloorAsync, GetProcedureStatsWindowFloorAsync and GetQueryStoreWindowFloorAsync (the viewer's data service) used to query the store for every range, including ranges where no "Showing since" note can show. The probe's answer is at or before the range's end, and the note needs it more than the 90-minute slack after the range's start, so for a range of 90 minutes or less the answer could never raise a note. Each method now returns null at once for one, with the same check and comment as DataWindowFloor.GetForServerAsync (endUtc - startUtc <= DurationTrendRouting.TruncationSlack). Coverage rule is unchanged: the later of the server's first collection and the purge edge.

The skip is in these three viewer methods and NOT in RawWindowFloor.GetAsync. Darling's MCP tools call GetAsync too (DarlingDataReader.GetQueryStatsWindowFloorAsync and its two siblings) and read its null as "nothing was read", so a skip inside it would make a short MCP window report that nothing was read. Each viewer method says so in a comment, and GetAsync's remarks say it too.

Caller check: every floor read in ViewerServerTab.Queries.cs goes through these methods. Three are the tab's loads (LoadTopQueriesAsync, LoadTopProceduresAsync, LoadQueryStoreAsync) and three are the slicer re-reads (OnQueryStatsSlicerChanged, OnProcStatsSlicerChanged, OnQueryStoreSlicerChanged). No ViewerServerTab*.cs file calls RawWindowFloor.GetAsync itself. A source test counts exactly two calls to each method and none to the shared probe. The banner text is unchanged for these ranges: a null floor and a floor inside the slack both leave UpdateTruncationBanner with nothing to name (the hourly-tier suffix and the interval-table plan are independent of the floor).

2. The two event-grid live test files run the tab's own step.
ViewerEventDataStartLiveTests.cs (Blocked Process Reports, Deadlocks) and ViewerEventGridsDataStartLiveTests.cs (System Events, Default Trace, Long Queries, and the row-cap cases) restated the banner rule in the test: they computed the notice with ViewerEventDataStart.Of and checked RawWindowFloor.IsTruncated. They now call ViewerServerTab.ShowEventDataStartAsync on a real banner control, through the shared QueryGridSeed.ReadBanner helper #4998 added, with the probe's answer and the row cap the tab passes (Blocked Process Reports also passes the capped source's start, as the tab does), and assert on the banner text (Showing since ..., or hidden). Every case and its intent is kept. The classes join the viewer-time-statics collection, because the banner's time text reads the process-wide display mode. One addition: the Blocked Process Reports full-page case also checks that the rows and the cap alone name the oldest row (with no capped-source start), so the rows-and-cap path stays pinned now that the tab's own call passes both.

Test plan

• Build of the test project and the viewer: 0 warnings, 0 errors.
• Item 1, RED then GREEN. Before the skip, ViewerShortWindowDataStartTests ran 24 tests and 6 failed: each of the three probes at 60 and at 90 minutes (a store nothing listens on, so a probe that starts its query throws). With the skip: 24 of 24 pass. These pass both before and after, as they should: each probe at 91 minutes starts its query and fails (3), a Darling MCP floor read over 60 and over 90 minutes still queries (6), and the caller census (1).
• Item 2, RED then GREEN. With ShowEventDataStartAsync ignoring its rows (a temporary change, restored), 14 of the 26 tests in the two files fail: ViewerEventDataStartLiveTests.cs 4 of 8, ViewerEventGridsDataStartLiveTests.cs 10 of 18 (6 of 12 in the System Events, Default Trace and Long Queries class; 4 of 6 in the row-cap class). The cases that stay green do not depend on the rows: a range that starts inside the coverage, a quiet start, and a read one row under its cap. Restored: 26 of 26 pass against a local PostgreSQL.
• Targeted classes without a store: ViewerShortWindowDataStartTests, the three live classes in the two files, every Viewer*DataStart* class, ViewerDataStartBannerTests, ViewerBlockedProcessReportsCoverageLiveTests, the five RawWindowFloor* classes, QueryStoreTopWindowTests, QueryStoreSliceTieBreakSourceTests, CSharpSourceWalkerTests, RepoFileAdoptionTests, DocCommentHygieneTests, CommentFilterAdoptionTests, LivePostgresCollectionHygieneTests: Total 331, Failed 0, Skipped 47 (the live ones).
• The same classes live against a local PostgreSQL: Total 331, Failed 0, Skipped 0.
• Full suite: not run (not asked for here).

Notes

• Lite's Queries tab already skips such a window. Its one floor-probe call (RefreshWindowTruncatedBannerAsync in ServerTab.Refresh.cs) goes through ProbeWindowFloorOrNullAsync, which returns null at once for a window of 90 minutes or less, so the two apps match.
• The new MCP tests prove "still queries" by pointing a floor read at a store nothing listens on and expecting it to throw. They do not read a populated store; the existing live MCP floor tests (RawWindowFloorMcpLiveTests) still pass and cover that.

CHANGELOG

No entry in this PR; the release owner adds it under [Unreleased]. Proposed entry:

• A range of 90 minutes or less on the Queries tab no longer reads the store for a note it could not show - the Query Stats, Procedure Stats and Query Store grids asked the store where their data starts for every range, including ranges of 90 minutes or less, where no "Showing since" note can appear. Those three reads now return at once for such a range; the Darling MCP tools are unchanged.