Cover the MCP Query Store regression reader's baseline lower bound in the census guard (#4310)

[erikdarlingdata]

Refs #4310.

Why

The #4310 census found DarlingQueryStoreRegressionReader.cs (the MCP twin of the viewer's
ViewerDataService.QueryStoreRegressions.cs) was not covered by the census guard: the grid's own
copy of the read has tests pinning the #4217 fixed-baseline-lookback lower bound
(ViewerQueryStoreRegressionsTests.RegressionsSql_SplitsBaselineBeforeWindow_RecentInWindow_OverTheBaseTable
asserts collection_time >= $5) and pins BaselineLookbackDays == 7
(BaselineLookbackDays_IsSevenDays_SameAsTheMcpReaderAndLite). The MCP reader's existing test file
(DarlingQueryStoreRegressionsTests.cs) had a same-shaped test
(RegressionsSql_SplitsBaselineFromRecent_OnTheSameBoundary) that asserted only the window split
(collection_time < $2 / >= $2 / <= $3) and never asserted the baseline's own fixed lower bound
(collection_time >= $6), nor did any test pin the reader's own BaselineLookbackDays constant. The
coverage probe (RegressionCoverageSql) had the same gap on its collection_time >= $4 baseline bound.

Checked the product code first: both bounds are already present in
DarlingQueryStoreRegressionReader.cs (collection_time >= $6 at line 114,
collection_time >= $4 at line 228) and BaselineLookbackDays = 7 is already declared. This is a
missing-guard defect, not a product defect — nothing was un-fixing; the ruling in the brief (the
grid's 7-day baseline bound stands for both copies) applies directly, so I added the assertions
rather than filing a product issue.

What changes (test-only)

Darling/Darling.Tests/DarlingQueryStoreRegressionsTests.cs:

• RegressionsSql_SplitsBaselineFromRecent_OnTheSameBoundary now also asserts
  collection_time >= $6 (the fixed baseline lower bound).
• New BaselineLookbackDays_IsSevenDays_SameAsTheViewerAndLite pins
  DarlingQueryStoreRegressionReader.BaselineLookbackDays == 7, mirroring the grid's own pin.
• CoverageSql_ProbesTheSameTable_ForBaselineAndRecent now also asserts collection_time >= $4
  on the coverage probe's baseline arm.

No product code touched.

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj -p:EnableWindowsTargeting=true: 0
  warnings, 0 errors.
• dotnet build Lite.Tests/Lite.Tests.csproj -p:EnableWindowsTargeting=true: 0 warnings, 0 errors.
• RED case (can't run net10.0-windows tests on macOS, so verified against the source text directly):
  temporarily replaced line 114 (AND collection_time >= $6) in
  DarlingQueryStoreRegressionReader.cs with a comment placeholder and confirmed
  grep -q "collection_time >= \$6" fails against the mutated file — i.e. the new assertion in
  RegressionsSql_SplitsBaselineFromRecent_OnTheSameBoundary would fail (RED) if the reader's
  fixed baseline bound were ever removed. Restored the file immediately after (verified via diff
  that the reader source is unchanged from origin/dev). The same reasoning applies symmetrically
  to the BaselineLookbackDays pin and the coverage-probe's $4 bound: each is a literal
  Assert.Contains/Assert.Equal against a fixed string/value that is only present in the current,
  already-fixed (get_query_store_regressions' baseline is every retained row before the window (no lower bound): 5–9 s per call on a large store, the slowest read on the web Queries tab #4195/WPF desktop viewer's Query Store Regressions grid still has an unbounded baseline (#4195 twin) #4217) source.
• Windows suite (Darling.Tests, net10.0-windows): unchecked here — builds but cannot run on macOS;
  CI decides it.

For the coordinator

Test-only change, no CHANGELOG entry. Branch fix/4310-census-guard-mcp-regressions, head
da76a2913cef2030faa22ee74d7a82839fd68d20, pushed to origin. Ready for a PR to be opened (draft).