CI's PostgreSQL test cluster loads pg_stat_statements, so its statement-count pins run instead of skipping

[erikdarlingdata]

Refs #4477.

Why

Three live pins count statements through pg_stat_statements: OverviewFleetHealthSingleFlightLiveTests and StoreSizeCacheLiveTests (both from #4482), plus WaitRateTileReadCountLiveTests. Each skips itself when the extension is not in shared_preload_libraries, because that setting is fixed at server start and cannot be turned on from inside a test. The gated-live CI cluster (build.yml's darling-pg job, and nightly.yml's copy of the same steps) preloaded only timescaledb, so all three passed vacuously — every CI run skipped, never ran, the statement-count assertion.

What changes

Both workflows' throwaway PostgreSQL cluster (port 5541, the one DARLING_TEST_PG points at) now preloads pg_stat_statements alongside timescaledb:

shared_preload_libraries = 'timescaledb'

becomes

shared_preload_libraries = 'timescaledb,pg_stat_statements'

nightly.yml stands up the same cluster shape for the same DARLING_TEST_PG-gated classes, so it gets the identical one-line change. The other three CI clusters (5542/5543/5544, the log-format clusters) are untouched — none of the three pins runs against them.

No test file changed. Each of the three pins already CREATE EXTENSION IF NOT EXISTS pg_stat_statements in its own scratch database and reads/reset that extension's counters scoped to that database's own dbid, so nothing in their isolation needed a fix.

Isolation (confirmed, no changes needed)

Pin	Own database	Reset scoped to its dbid	Query-text filter
OverviewFleetHealthSingleFlightLiveTests	Own ScratchPostgres database (#1776 own-store)	pg_stat_statements_reset(0, $dbid, 0) before the pin's own read	query LIKE '%v_collection_log%' AND query LIKE '%last_zero_row_streak_break_time%', filtered by dbid = $1
StoreSizeCacheLiveTests	Own ScratchPostgres database	pg_stat_statements_reset(0, $dbid, 0)	query LIKE '%pg_database_size%current_database%', filtered by dbid = $1
WaitRateTileReadCountLiveTests	Own ScratchPostgres database (moved here for exactly this reason — see the class's own remarks)	pg_stat_statements_reset(0, $dbid, 0)	query LIKE '%peak_ms_per_sec%' AND query LIKE '%v_wait_stats%', filtered by dbid = $1

pg_stat_statements' counters are cluster-wide, keyed by dbid, not private per database — every reset and read above filters on that scratch database's own oid, so each of the three can run in parallel with any other live class on the same cluster without stepping on another class's in-flight count. None of the three needs [Collection("live-postgres")].

Other classes checked

Preloading the extension could change what other live classes see, because some use this cluster as a PostgreSQL target. every class under Darling/Darling.Tests that mentions pg_stat_statements, shared_preload_libraries or pgss and also runs against DARLING_TEST_PG was inventoried and read. Result: none of them assumed the extension absent as a fixed fact.

Class	Why it's safe with the extension now loaded
StoreStatementStatsLiveTests (3 tests gated on DARLING_TEST_PG)	Each probes IsPreloadedAsync itself first and branches its own expected outcome (Ready vs NotPreloaded) on the live answer — adapts to either state by construction.
ServerWatermarkCacheRunnerLiveTests	Counts through Npgsql's own command-execution debug log, never through pg_stat_statements; no assertion depends on preload state.
DarlingMcpPgLoggingAuditToolsTests / ...LivePostgresTests	Seeds its own snapshot rows into a table and asserts against those seeded values; never reads live pg_settings/shared_preload_libraries.
CollectorStateContractTests, DarlingAnomalyBaselineTests, DarlingCappedReadLivePostgresTests, DarlingMcpPgPlanToolsTests, DarlingPgTopQueriesLiveTests, DeltaFamilyIntervalCompletionLivePostgresTests, McpCollectionLogPerServerResponseBudgetLivePostgresTests, PgLogEventMetricsTests, PgStatementTextSourceTests, RawPurgeConvergeLiveTests, RuntimePreconditionMissTests	Mention pg_stat_statements only in doc comments, string-literal SQL under test, or unit-level (non-live) string assertions (PostgresFaultOutcomeTests, StoreStatementStatsTests) — none reads the live cluster's actual preload state.
CiComposeWorkerSizingTests / CiClusterWorkerSizingTests (the census pins)	CiClusterWorkerSizingTests parses only the worker-count settings (timescaledb.max_background_workers, max_worker_processes), not shared_preload_libraries — no update needed. CiComposeWorkerSizingTests asserts against docker-compose.yml's already-correct shared_preload_libraries=timescaledb,pg_stat_statements, a different file that stays untouched here.

Test plan

• Both workflow files: 0 errors on dotnet build for Darling.Tests.csproj and Lite.Tests.csproj (macOS, EnableWindowsTargeting=true).
• On a local rig preloading both timescaledb and pg_stat_statements: all three target pins run and pass (not skip). The classes listed above plus the census pins (CiComposeWorkerSizingTests, CiClusterWorkerSizingTests) and DocCommentHygieneTests all pass on the same rig — 203 total, 0 failed, 1 expected unrelated skip.
• CI proof: on this PR all three PostgreSQL shards pass and none of the three pins is in any shard's SKIP list (StoreSizeCacheLiveTests runs in shard 1; WaitRateTileReadCountLiveTests and OverviewFleetHealthSingleFlightLiveTests in shard 2). On Not for merge: prove the statement-count pins fail in CI under one mutation each #4484 (closed, not merged), the same change plus one mutation per pin, CI failed exactly those three pins, one per mutation.

CHANGELOG

None: a CI and test-only change; no shipped behavior changes.