get_pg_server_config, get_pg_logging_audit and the PostgreSQL config panel plan a day's chunks, not every retained pg_server_config chunk (#3974)

[erikdarlingdata]

Closes #3974.

Why

DarlingPgServerConfigReader.CurrentConfigSql and OverrideSql (get_pg_server_config, and the WPF
viewer's PostgreSQL config panel) and DarlingPgLoggingAuditReader.NewestSnapshotSql
(get_pg_logging_audit) had no lower bound on the newest-snapshot anchor or the row scan. pg_server_config
keeps 365 days of hourly snapshots in one-day chunks, so TimescaleDB had to plan every retained chunk before
reading a row on every call.

What changes

• CurrentConfigSql and NewestSnapshotSql get the PostgreSQL-target config reads plan every retained pg_server_config chunk: seconds per read once a store holds a year of snapshots #3928 shape exactly: a day's lower bound on both the
  anchor's MAX(collection_time) and the outer row scan, with a fallback to unbounded only when the day
  found nothing (DarlingPgServerConfigReader.ConfigSnapshotLowerBounds, shared by both readers).
• OverrideSql needed a different shape - the design question the issue raised. Most servers have zero
  per-database/per-role overrides, so retrying on "the read returned no rows" would run the unbounded
  fallback on nearly every call, defeating the fix. Instead the anchor is a one-row CTE LEFT JOINed to the
  override rows, so its collection_time rides on every call even with zero overrides; the retry loop keys
  on that column, never on row count.
• Results are unchanged: a target whose config collector has gone dark for more than a day still gets its
  newest snapshot however old, through the same fallback rung these reads always had.

Test plan

• PgServerConfigToolBoundTests (new): pins the bound on all three statements, the day-first/fallback
  loop at each call site (keyed on row count for two, on the anchor column for OverrideSql), and the
  bounds themselves.
• PgServerConfigTests.TheCurrentReadAnchorsOnTheNewestSnapshot_NeverComingUpEmptyForADarkServer
  updated: the old pin asserted "no collection_time >= anywhere"; the property that matters (a dark
  target never comes up empty) still holds, now through a bound-plus-guaranteed-fallback rather than no
  bound at all.
• PgServerConfigOverrideLivePostgresTests (existing, gated): its hand-built CurrentConfigSql call
  updated for the new $4 parameter; still green.
• PgServerConfigToolBoundLiveTests (new, gated DARLING_TEST_PG): seeds 11 daily chunks and EXPLAINs
  all three reads with each bound - the day plans 1-4 chunk scans, the fallback plans all 11; a dark
  target (72h) still answers with its newest snapshot on all three reads; a snapshot with zero overrides
  does not fall back and leak an older snapshot's overrides (the case the design question was about).
• Measured on the rig (366 one-day chunks, PostgreSQL 18.6 / TimescaleDB 2.30.1): unbounded planning
  21-288 ms (812-12,592 buffers) against ~2.9-3.0 ms bounded (812 buffers) with a literal-equivalent
  bound - the same order of magnitude the issue measured (4.0-8.3s at full 365-day retention; this rig's
  warm/cold variance was noisier than the issue's but the bounded shape was consistently ~7x+ cheaper at
  every measurement).
• Targeted: Darling.Tests PgServerConfig/PgLoggingAudit classes, 64 total, 0 failed (7 skipped - ungated
  live tests).
• Full suite: Darling.Tests, 12,934 total, 0 failed (1 pre-existing flake in
  TimescaleSupportTests.EndToEnd_RetentionPoliciesActuallyApply_AndAreCreatedPaused_AgainstDevPostgres,
  confirmed passing alone, unrelated to this change - not touched by this PR).

Lite and the Dashboard do not monitor PostgreSQL, so there is no parity item.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv