Extend the shared DuckDB fixture to 20 fast-bucket test classes

[erikdarlingdata]

Summary

Round three of the Lite.Tests speed campaign (#1693 shared fixtures for the heavy seven, #1694 batched seeding): a full-suite trx profile showed 400s+ of serial weight remaining in fast-bucket classes with the same per-test disease - a fresh DuckDB and full schema build inside every test, and in several classes per-row single-connection seeding. This PR extends SharedDuckDbFixture to 20 more classes.

Stacked on #1694; once it merges, this diff collapses to the fast-bucket commits.

Converted

Fixture + data-only reset per test, plus a per-instance shared seed connection where the class hand-rolls inserts: IndexObjectStats, PerformanceCalendarData, StoreRoundTrip, SystemEventsReader, BlockingStatsReader, ConfigChangesReader, CollectionHealthWindow, QueryStatsModuleAttributionReader, FinOps, FactScorer, FindingStore, AnalysisNotification, DatabaseFilter, DailySummaryHighCpu, McpStatusEnvelope, McpAnalysisFindingsCommand, and the four appender round-trip classes (CollectorPlanColumn, CpuSchedulerPlanCache, SessionSummaryStats, SystemHealthEvents), which previously built one database per table per test.

Special handling, called out because each was a place this refactor could have gone wrong:

• FindingStoreTests has a genuine pristine-schema test: the analysis-schema v3->v4 migration test hand-creates the legacy table shape (CREATE TABLE analysis_findings would collide on the fixture's current schema). It now runs on its own private database file; its 15 siblings share the fixture.
• The two MCP classes keep a test-local temp dir for the ServerManager config directory; only the database is shared.
• The [Collection("server-time-helper")] trio keeps its collection attribute (class fixtures compose with named collections).

Deliberately NOT converted

Each of these needs a private database by design, and converting them is exactly how a shared fixture poisons tests:

• ArchiveViewDedupTests - writes parquet and rebuilds archive views.
• MuteRulesSurviveResetTests - drives ArchiveAllAndResetAsync, which deletes the database file (ResetDatabaseAsync).
• DuckDbSchemaTests - tests schema creation and init idempotency itself.
• AlertHistorySourceTests / DismissedArchiveSidecarTests / DismissReliabilityTests - their TestAlertDataHelper writes parquet into the database's archive directory and rebuilds views.
• LiteAlertForwardingTests - a single DB-touching test; not worth a fixture.

Measured (full-suite trx, same box, contended-parallel conditions)

Class	Before	After
Total serial work (1494 tests)	925s	760s (-18%)
IndexObjectStatsTests	60.6s	20.8s
SystemEventsReaderTests	36.2s	13.8s
PerformanceCalendarDataTests	27.0s	off the top-15
BlockingStatsReader / ConfigChangesReader	24.5s / 20.9s	off the top-15

Local full-suite wall time is now parallelism-bound (~87-100s on a many-core box; the removed work was parallel slack). CI's 2-core runner is serial-bound, so the ~165s of eliminated work should translate there nearly 1:1 - the fast-tests step is the one to watch on this PR's CI run.

Isolation proof

• Full suite run twice consecutively, same session: identical results, 1494/1494 passed, 0 failed both runs.
• Build at zero warnings.
• Eligibility was read per class before converting (the NOT-converted list above is the output of that read), so no test that depends on a pristine schema or file shares a database.

Generated with Claude Code