Bucket the Darling viewer's File I/O and memory clerk trend charts (#4234)

[erikdarlingdata]

Part of #4234.

Why

The WPF Darling viewer's File I/O tab and Memory tab's clerk chart read every collection in the
window instead of bucketing, the same problem #4234 already fixed for Wait Stats and Perfmon in
PR #4304. Per #4234's body, one production store returned 85,010 File I/O rows for a 7-day window.
The memory clerk trend has the same shape (up to 20 clerks, one row per collection each).

What changes

Following PR #4304's pattern (WaitTrendsSql, ViewerNameListCache) exactly, per the ruling at
issuecomment-5834669118:

• ViewerDataService.FileIo.cs - FileIoLatencyTrendSql and FileIoThroughputTrendSql now
  group into date_bin buckets sized by TrendBuckets.AutoMinutes(windowMinutes, 1, TrendBudget.Chart.AutoPoints), the same sizing the MCP trend reads use. Latency averages summed
  stall-ms over summed read/write count deltas per bucket; throughput sums byte deltas over summed
  interval-seconds (time-weighted, never an average of per-collection rates). The existing top-10-files
  limit is unchanged. A bucket holding exactly one physical collection (rated or not — matching
  WaitTrendsSql's documented rule) is stamped at that collection's own raw collection_time instead
  of the bucket's date_bin grid line.
• A rated CTE now carries the Measurement-layer campaign: the delta honesty contract (11 findings, one keystone) #3540 "interval 0 is unknowable" rule (previously a WHERE
  filter that dropped the row outright) as a per-row CASE null-out, so an unrated row still counts
  toward collection_count for singleton detection but never contributes to a bucket's sums. A new
  HAVING COUNT(rated_reads) > 0 / HAVING COUNT(rated_seconds) > 0 preserves the pre-bucket "absent,
  not 0.00" answer for a bucket where every row was unrated.
• ViewerDataService.Memory.cs - MemoryClerkTrendsSql (up to 20 clerks) now buckets as a gauge
  (AVG(memory_mb) per bucket, no rate math — a clerk's memory_mb is a point-in-time reading, not an
  accumulating counter), with the same singleton-stamping rule. DistinctMemoryClerkTypesSql (the
  clerk picker's population read) now sits behind ViewerNameListCache
  (GetDistinctMemoryClerkTypesAsync gained an optional nowUtc clock seam, default null so every
  existing 3-arg call site is unaffected), same as DistinctWaitTypesSql in PR WPF Wait Stats and Perfmon trend charts bucket server-side (#4234) #4304: a full-window
  DISTINCT runs at most once per 15 minutes per (server, window length), and a hit also requires the
  cached window's end to sit within the TTL of the requested end.
• MemoryGrantTrendSql, MemoryGrantChartDataSql, LatestMemoryStatsSql, and
  MemoryPressureEventsSql are untouched, per the brief's scope.
• PerformanceMonitor.Common.csproj gained the PerformanceMonitor.Darling.Viewer InternalsVisibleTo
  grant and Darling/PerformanceMonitor.Darling.Viewer/ViewerNameListCache.cs was added — both copied
  verbatim from PR WPF Wait Stats and Perfmon trend charts bucket server-side (#4234) #4304's pattern before that PR merged into dev out from under this branch (see
  "Timing note" below); after merging origin/dev, both turned out byte-identical to what WPF Wait Stats and Perfmon trend charts bucket server-side (#4234) #4304 landed,
  so the merge picked them up cleanly with no conflict.
• All four downstream callers (ViewerServerTab.FileIo.cs, ViewerServerTab.Memory.cs,
  CorrelatedTimelineLanesControl.xaml.cs) consume the same record shapes unchanged; none assume a
  fixed point spacing, and the two chart renderers already do their own per-series GroupBy +
  OrderBy(CollectionTime), so the SQL's new series-first ORDER BY (mirroring WaitTrendsSql,
  instead of the old collection-time-first order) needed no renderer changes.

Timing note

origin/dev didn't have PR #4304 merged when this branch was created, so the branch started by
copying ViewerNameListCache.cs and the csproj edit from that PR's branch by hand. #4304 merged to
dev partway through this lane's work; merging origin/dev afterward picked up the real files
cleanly (byte-identical, no conflict) and also brought in the real ViewerTrendBucketingReviewTests.cs
this brief pointed at.

Test plan

Ran from Darling.Tests.exe (MTP), against a throwaway PostgreSQL 18 + TimescaleDB rig
(postgresql.conf forced to UTC to match CI), darlingtest database, after merging origin/dev:

• Darling/Darling.Tests/Darling.Tests.csproj builds with 0 Warning(s), 0 Error(s).
• ViewerFileIoBlockingSqlTests, ViewerFileIoBlockingLivePostgresTests,
  ViewerMemorySqlTests, ViewerMemoryPickerLogicTests, ViewerMemoryLivePostgresTests,
  ViewerTrendBucketWidthSqlTests, ViewerNameListCacheTests, ViewerTrendBucketingLiveTests,
  DocCommentHygieneTests - 149/149 pass, 0 failed.
• Updated the pre-existing SQL-text assertions in ViewerFileIoBlockingSqlTests /
  ViewerMemorySqlTests that the bucketing rewrite made stale (GROUP BY/ORDER BY shape, the
  rated-CTE column names, the CAST(memory_mb...) literal).
• Added the ruling's four required tests per read (source bucket-width check; live 7-day-window
  row-budget cap; live point equality with the old shape when every bucket holds one collection,
  seeded off the minute grid at :37 seconds; for the clerk picker, a live proof that a second call
  inside 15 minutes answers from cache and a window end past the TTL misses even within the
  wall-clock TTL).
• Proved the regression pins fail on the pre-bucketing code: temporarily swapped in
  origin/dev's (pre-this-PR) ViewerDataService.FileIo.cs and ViewerDataService.Memory.cs,
  rebuilt, and re-ran just the two new 7-day-budget-cap tests - both failed (too many rows) as
  expected, confirming they're real regression pins. The two singleton point-equality tests
  passed even against old code too, which is expected and consistent with WaitTrendsSql's own
  test suite: old code always returned raw unbucketed points, so it trivially satisfies "raw
  timestamps unchanged" - that test's value is catching a future regression that buckets without
  singleton detection, not distinguishing old from new. Restored both files to the bucketed version
  afterward and re-ran the full 149 to confirm.
• Caught one bug this way: my first cut of the throughput singleton test used a byte delta
  calibrated for a 60-second collection interval, but its three seeded points are 5 minutes apart -
  it read 0.2 MB/s instead of the intended 1.0. Fixed in a follow-up commit once I actually ran it.
• Full suite: not run here, per this lane's brief (CI runs it).
• Live Darling viewer app: not exercised manually.

CHANGELOG entry

SECTION: Changed
ENTRY:

• Darling viewer's File I/O and memory clerk charts load faster over long windows ([Bucket the Darling viewer's File I/O and memory clerk trend charts (#4234) #4329]) - the
  File I/O tab's Latency and Throughput charts and the Memory tab's clerk trend used to fetch every
  raw collection in the selected window (measured 85,010 rows for one store's File I/O tab over 7
  days); they now bucket server-side to a fixed point budget per line, with the same time bucketing the
  MCP trend reads use. A window small enough that every bucket holds one collection still renders the exact
  same points at their original timestamps. The memory clerk picker's name list is now cached for 15
  minutes instead of re-querying on every auto-refresh.
  REF:
  [Bucket the Darling viewer's File I/O and memory clerk trend charts (#4234) #4329]: Bucket the Darling viewer's File I/O and memory clerk trend charts (#4234) #4329

🤖 Generated with Claude Code

https://claude.ai/code/session_01FVjn4PBJN71NQXdFo6ZxNQ