Batch DuckDB test seeding: shared connection + one transaction per seed helper

[erikdarlingdata]

Summary

The follow-up #1693's profiling demanded: the analysis-heavy filter's remaining cost was not schema DDL but seeding I/O. Every seeded row opened a fresh DuckDB connection and auto-committed a single INSERT - measured at ~90ms per row - and AnomalyDetectorTests' 100-200-row seeds alone were the filter's entire critical path (154.5s serial of its ~154s wall).

Stacked on #1693 (auto-merge armed); once it lands, this diff collapses to the batching commits only.

What changed

• AnomalyDetectorTests / BaselineProviderTests: a per-test-instance seed connection reused for every row; the seven SeedBaseline* loops in AnomalyDetectorTests each run inside one BEGIN/COMMIT.
• TestDataSeeder: one lazily-opened connection per seeder instance, and every seed helper wraps its inserts in a SeedBatch (BEGIN on create, COMMIT on dispose) so a helper's rows share one WAL flush instead of paying an auto-commit apiece. ClearTestDataAsync deliberately stays un-batched: its per-table try/catch DELETEs would abort an explicit transaction on the first missing table and silently skip the rest of the clear.
• TestDataSeeder is now IDisposable (it owns the connection); all 48 construction sites take using var seeder. Four classes outside the heavy filter (DatabaseFilter, FactScorer, FinOps, FindingStore) use the seeder too and get the same speedup for free.

Measured (local, idle box, Debug, --no-build)

Run	Before (#1693 alone)	After
Analysis-heavy filter (153 tests)	164s	19s
Full suite (1494 tests)	233s	78s

Per-class serial totals (trx): AnomalyDetector 154.5s -> 5.9s, FactCollector 116.8s -> 20.0s, Scenario 103.9s -> 17.2s, Misery 55.2s -> 10.2s, AnalysisService 32.1s -> 5.7s, Inference 25.9s -> 5.2s, BaselineProvider 30.0s -> 4.5s. No class above 20s serial.

For honesty's sake: #1693's own CI run showed the fixture alone was NET NEUTRAL on the runner ("Run Lite analysis-heavy tests" 612s vs the 556s reference, with the fast step drifting +10% the same way - runner variance). The per-row seeding cost was the real bottleneck all along; this PR is the one that should collapse that CI step.

Isolation proof

Same standard as #1693, re-proven here because transaction semantics changed:

• Full suite run twice consecutively, same session: identical results, 1494/1494 passed, 0 failed, 0 skipped, both runs.
• Batches commit before any test reads (reads happen after seed helpers return), so no test can observe uncommitted rows.
• A helper that throws mid-batch leaves the test failing anyway; SeedBatch.Dispose commits best-effort and swallows its own error so it can never mask the test's real exception.
• Build stays at zero warnings.

Generated with Claude Code