Say where the data starts on every time-ranged tab, in Lite and both Darling viewers #4966

What happens

When a time range starts before a server's data coverage, most tabs draw the shorter range with no notice. Coverage starts at the later of the server's first collection by the table's collector and the table's retention edge. Retention or a newly added server can put it after the range's start. A reader can take the missing span for a quiet period.

#4953 adds a "where the data starts" notice to Custom Views panels, and to Active Queries and Current Waits in Lite and the Darling viewer. The Queries tab and its MCP tools already had one. This issue covers every other time-ranged surface.

Lite: 48 surfaces

The list comes from #4958. Each table's retention and read shape was not checked. (seen: the list)

• Overview and Wait Stats.
• Queries: Performance Trends, Plan Corrections and Query Heatmap.
• CPU, Memory (4 sub-tabs), File I/O (2), tempdb, Perfmon, Running Jobs, Daily Summary, Latches and Spinlocks, CPU Scheduler, Plan Cache and Session Stats.
• Blocking: Trends, Blocked Process Reports, Deadlocks and Blocking Stats.
• Collection Health (3), System Events (11), Config Changes (3) and Long Queries.
• Configuration (6 sub-tabs). These may read only the newest snapshot, which needs no notice. (inferred)
• The other MCP tools that take a time range.

Darling desktop viewer

Tabs over tables that keep 30 days can show a custom range past 30 days with no notice. A new server's short history shows the same way. Only Active Queries, Current Waits and the Queries tab carry the banner. (inferred until each tab is checked)

Darling web viewer

The server page offers ranges up to 7 days. It shows a notice when a read's own limit narrows the window (keptWindowStrip in util.js). The query trend panel also notes window_truncated. No other panel says where the stored rows start. So a server added 2 days ago shows 2 days under "last 7 days" with no notice. (inferred from the page code)

How

The parts exist already:

• The notice keys on where collection or retention starts, not on the oldest stored row. A sparse table can hold no row near the range's start though the store covered it, and that is no reason for a notice.
• Lite: GetQueryWindowFloorAsync takes a closed set of views (QueryWindowRelation). For a coverage view, the collector's runs in v_collection_log count as well as rows. Each new surface needs an enum member, its view and the collector it reads coverage from. It also needs a banner, and a call at each read path through ApplyWindowFloorToBanner.
• Darling: DataWindowFloor probes any collector table whose index leads with (server_id, <time>). Coverage starts at the later of the registry's created_date and the purge edge from the fleet schedule. A table the schedule gives no edge keeps its oldest row. The viewer and the web runner already call it.
• Check each surface first. A tab that reads only the newest snapshot needs no notice. A chart whose time axis spans the asked range already shows the empty span. A grid or a list hides it.

Done when

• Each surface in the three lists has a result: a notice, or the reason it needs none.
• Each surface that gets a notice has a test that stores rows starting inside the range and reads the notice back.
• Each one also has a quiet-start test: the store covered the whole range, but its first row comes late. It shows no notice.