Top-N raw reads apply the hourly rollups' zero-interval filter, so both tiers agree by construction (#4394)

[erikdarlingdata]

Refs #4394.

Why

The hourly successors exclude zero-interval rows (sample_interval_seconds = 0): their CREATE bakes in TimescaleSupport.IntervalHonestSourceFilter (sample_interval_seconds IS DISTINCT FROM 0). The raw top-N reads did not carry the same filter, so the two tiers answered the same window through different row sets.

In real data that difference is empty. The collector writes a zero-interval row with zero deltas: CollectorDeltaCalculator returns (delta 0, interval 0) for a first sighting, a counter reset, and a gap past the delta policy, and a first sighting that did real work (#2235) carries its real interval. A 24-hour count on two production SQL Server stores found delta_worker_time summing to exactly 0 over every zero-interval row. So this change moves no CPU figure. It applies the filter so that a raw-served and an hourly-served read agree by construction, instead of by the collector's invariant (see #4394's close-out).

What changes

Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingDataReader.cs: TopQueriesSql,
TopQueriesByHostObjectSql and TopProceduresSql each gain
AND {TimescaleSupport.IntervalHonestSourceFilter} in their WHERE clause, through the one
shared constant (matching the file's existing pattern of interpolating Storage constants into
$""" raw strings) — never a copied literal. TopQueriesHourlySql is untouched; it already
inherits the filter from its successor's CREATE.

Test plan

• Unit (SQL shape): the three consts' text contains the filter. RED on dev (the consts
  don't emit it there); GREEN on the branch. Build: Darling.Tests 0 warnings / 0 errors,
  Lite.Tests 0/0 (build-only on macOS; both target net10.0-windows, CI runs them).
• Live (the pin Raw top-N reads sum zero-interval first-collection rows that the interval-honest rollups exclude #4394 asks for), extending TopQueriesHourlyRoutingLiveTests.cs:
  GetTopQueriesByCpuRoutedAsync_RoutesToHourlyOnceRawIsPurged_AndTotalsAgree now seeds a
  zero-interval row for a group that also has ordinary rows (0xTOPQ1), on top of the
  existing zero-interval-only group (0xZEROINTERVAL). Both are routed through
  GetTopQueriesByCpuRoutedAsync (raw, then hourly with a fresh NpgsqlDataSource for the
  5-minute coverage cache), never by reading either table's SQL directly.
  • RED on dev (pre-fix, run in-process on macOS against a throwaway TimescaleDB container,
    timescale/timescaledb:2.30.1-pg18): raw's 0xTOPQ1 total (17 executions / 1,500,000
    CPU-us) exceeds hourly's (16 executions / 800,000 CPU-us) by exactly the zero-interval row's
    delta — [FAIL] at the assertion "a hash whose only rows are zero-interval is excluded from raw's own read by #4394's fix" (line 107 of the pinned test).
  • GREEN on the branch: Darling.Tests.TopQueriesHourlyRoutingLiveTests — Total: 2, Errors: 0, Failed: 0.
  • TopProceduresSql has no routed read yet (its hourly routing is Route get_top_procedures_by_cpu and the Top Procedures grid to the hourly rollup (#4231) #4413, not yet on dev), so it's covered only by the unit shape pin above; a routed live pin for procedures
    is follow-on work once Route get_top_procedures_by_cpu and the Top Procedures grid to the hourly rollup (#4231) #4413 (At "Last 7 days" the WPF Queries grids silently show ~4 days: Top Queries, Top Procedures and Query Store read raw tables dropped at 4 days, with no floor disclosure (get_query_store_top got one in #2364; the viewer and the query-stats MCP tools didn't) #4231's procedure routing) is on dev.
• Also run (all green): TopQueriesHourlyRoutingTests, IntervalHonestHourlyRollupTests,
  LiveCleanupConversionRatchetTests, StorageCommandTimeoutTests,
  StartupCommandTimeoutTests, DocCommentHygiene, AlertReadFailureSurfaceTests.
  LivePostgresCollectionHygieneTests.EveryClassUsingTheSharedStore_IsSerializedOrDocumentsWhyNot
  fails on macOS only, with PresentationFramework missing after the runtimeconfig strip needed
  to run Darling.Tests.dll in-process here (a reflection-over-all-types scan hits a WPF-typed
  class); pre-existing and unrelated to this change — CI decides it on Windows.

Ranking on the test seed

The seed plants a zero-interval row with a nonzero delta, a shape the collector does not write, so that the filter is observable:

Window WindowStart..WindowStart+1d, 0xTOPQ1 carries an ordinary row (500,000 CPU-us / 10
executions), a second ordinary row (300,000 CPU-us / 6 executions), and one zero-interval row
(700,000 CPU-us / 1 execution):

Tier	Before (dev)	After (branch)
Raw, 0xTOPQ1 total	1,500,000 CPU-us / 17 executions	800,000 CPU-us / 16 executions
Hourly, 0xTOPQ1 total (unchanged either side)	800,000 CPU-us / 16 executions	800,000 CPU-us / 16 executions

Before: raw and hourly disagreed by the planted row's delta. After: raw's own read
now excludes that row the same way the hourly successor's CREATE always has, so the two tiers
agree on the same window.

CHANGELOG entry

SECTION: None
ENTRY: None: raw and hourly top-N reads now apply the same row filter; no figure changes in real data (#4394).