slow_reads and read_latency record no window when the caller took the default or the route fixes it #5814

Claude posting for Erik Darling.

Field (store A, pm-worker, 2026-10-14)

29 of the 30 slow get_query_store_query_history rows in slow_reads record no window, though that read is always bounded: hours_back defaults to 24 and ValidateWindow runs first (Darling/PerformanceMonitor.Darling.Service/Mcp/DarlingMcpQueryStoreHistoryTools.cs near line 262). The get_collection_health rows carry no window either; its window is fixed at 7 days inside the statement.

Code

SlowReadLog.NormaliseArguments (Darling/PerformanceMonitor.Darling.Service/SlowReadLog.cs near line 249) lifts a window only from an hours or hours_back key the caller passed. A defaulted window is not recorded, and a route whose window is fixed in code never records one. V182 (#5792) derives window_band for read_latency from the same arguments, so defaulted calls land in the no-window band there too (check).

Fix

• The slow-read row and the read-latency band record the effective window, the one the read ran with, default included: the tool sets it after it resolves its arguments, and a route with a fixed window records that window.
• get_slow_reads and get_read_latency then band a defaulted call like an explicit one.
• A test logs a defaulted history call and sees the 24 h band, and a collection health call and sees the 7 d band.