test-presence gate false-positives on every Drizzle migration (.sql unmatchable by isRelated)

[veksen]

What

The test-presence gate (src/gate/test-presence.ts) emits its "Unverified — no related data-layer test" warning on every Drizzle migration in a PR, even when the migration's effect is fully exercised by real-DB tests. It fires on every migration PR, so the signal gets tuned out.

Observed on Query-Doctor/Site PR #3518: the only flagged file was apps/api/drizzle/0040_add_resurface_timing_and_config.sql, despite that PR's new columns being written and read back by testcontainers-backed repository integration tests.

Root cause

Two mechanics combine so a migration can never be matched to its test by isRelated(dataAccessPath, testPath):

1. Classified as data-access. .sql is in sourceFilePatterns and ALTER TABLE / CREATE TABLE match queryCodePatterns, so the migration lands in dataAccessChanged.
2. Unmatchable to any test. isRelated accepts a test only by same directory or stem containment. A migration lives in apps/api/drizzle/ (a test never will), and baseStem() strips .test/.spec and JS/TS/py/go/rb extensions but not .sql — so the migration's stem is its whole filename (0040_add_resurface_timing_and_config.sql), which appears in no test name. Both checks always fail.

So the gate's claim ("nothing exercises this against Postgres") is false for any project whose migrations are applied + asserted by repository/integration tests — it just can't see the coverage.

Suggested fixes (either or both)

• Strip .sql in baseStem() so a migration's stem isn't its full filename (marginal — migration names still won't match module-named specs, so this alone won't fix it).
• Treat a migration file as covered when any data-layer test changed in the PR (a migration has no 1:1 test; its correctness is verified by the suite that runs against the migrated schema). This is the real fix.
• Expose it through the per-repo TestPresenceConfig override (#3500) so a repo can exclude drizzle/*.sql.

Context

Warn-only gate (#3496); the capture-based precision rungs (#3502/#3503) would also resolve this once queries are mapped at runtime, but the migration false-positive is worth fixing before then since it fires constantly.