Make the #1912 destroy-pin test self-sufficient under a pinned search path (#1940)

[erikdarlingdata]

The test builds a raw scratch hypertable with no migrations; under the local-rig recipe's SearchPath=collect,config pin the scratch database has no writable schema on the path (3F000) and the extension's functions would not resolve. Session path set explicitly with the why-comment; sibling tests migrate first and were never exposed. Proven green under BOTH connection-string flavors on a fresh rig; pre-existing failure proof is on the issue.

🤖 Generated with Claude Code

[claude]

This entry links [#1940], but there's no matching reference-link definition ([#1940]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/1940) in the definitions block near the end of the file — every neighboring entry ([#1937], [#1939], [#1934], etc.) has one. As written, [#1940] will render as literal bracketed text instead of a hyperlink. Please add the missing definition alongside the others.

[claude]

Review

Small, well-scoped fix. Summary of what I checked:

What the PR does: Adds SET search_path = public at the top of ARefreshEntirelyBelowRawsFloor_DestroysMaterializedHistory_WhichIsWhyTheRepairIsClamped in Darling/Darling.Tests/QueryStoreSliceRepairLiveTests.cs. That test builds a raw scratch hypertable directly (no PgMigrations.MigrateAsync), so it has no collect/config schemas. If DARLING_TEST_PG carries a SearchPath=collect,config pin (a local dev-rig convention), bare CREATE TABLE/extension calls fail with 3F000 since neither schema exists in the fresh scratch DB. Pinning the session to public — which every freshly created Postgres database has — makes the test self-sufficient regardless of the ambient connection string's search path.

Correctness

• Verified this is the only test in Darling.Tests that calls ScratchPostgres.CreateAsync without following up with PgMigrations.MigrateAsync (checked QueryStoreCorrectedRollupLiveTests, RollupBackfillLiveTests, DarlingDeliveryModeTests, DarlingAlertTuningKnobsTests, RetentionChunkGeometryLiveTests, LivePostgresCollectionHygieneTests — all migrate first, so they're unaffected by the described bug and don't need the same fix).
• The sibling tests in the same class insert through schema-qualified names (collect.query_store_stats), so they're search-path independent already, consistent with the new comment's claim.
• Behavior under CI's bare connection string is unchanged: Postgres's default search path already resolves to public first for a fresh role, so this only removes a latent dependency on that default rather than changing CI's current pass/fail outcome.
• Fix is minimal and placed at the earliest point in the test (right after OpenAsync, before any DDL) — no other ordering issues found.

Lite/Darling parity: Not applicable here — search_path is a Postgres/Timescale-only concept, and Lite.Tests has no Postgres or search_path usage at all. This is a Darling-only test infra fix with no Lite counterpart to update.

Security / performance: None of concern — test-only code, no user input, no new network/file/process surface.

One issue found (left as an inline comment): the new CHANGELOG entry links [#1940] but the corresponding reference-link definition ([#1940]: https://.../issues/1940) wasn't added near the bottom of the file, unlike every neighboring entry. As-is it'll render as literal bracket text rather than a link.