fix(gate): match DDL by statement shape, not keyword adjacency

[veksen]

Goal

The test-presence gate should only flag PRs that actually change query code. Site#3539 — a pure MCP tool rename with zero SQL changes — got the "changes queries with no related data-layer test" warning. This PR removes that class of false positive. It is the whole fix; no follow-up step.

What

Before: any added diff line containing CREATE INDEX / ALTER TABLE / etc. as adjacent words classified the file as changed data-access code — including prose inside a string literal (Site#3539's tool description says "its suggested CREATE INDEX fix"). After: prose mentioning DDL keywords no longer trips the gate; real DDL statements still do.

How

src/gate/test-presence.ts: the single keyword-adjacency DDL pattern becomes five statement-shaped ones — CREATE [UNIQUE] INDEX … ON, CREATE TABLE … (, CREATE [OR REPLACE] [MATERIALIZED] VIEW … AS, ALTER TABLE <ident>, DROP TABLE/INDEX/VIEW <ident>. The discriminator is the statement's own grammar (ON clause, column list, target identifier), because the alternative — stripping string literals before matching — would blind the raw-SQL patterns whose whole job is catching SQL in strings.

Verified end-to-end against Site#3539's actual GitHub patch data (pulls/3539/files): the old gate classifies packages/mcp-server/src/tools/index.ts as data-access and emits the untested-data-access verdict; the patched gate returns null. Also confirmed against prod that the capture override could never have suppressed this flag (the run captured 0 new hashes vs its staging baseline — a rename adds no query surface), so the content heuristic is the only place this false positive can die.

Known limit, unchanged by this PR: a string literal containing a full SELECT … FROM sentence can still trip the select pattern. That shape is indistinguishable from a real raw-SQL query at the diff level; the capture-based rungs (#3502/#3503) are the durable answer there.

Tests

src/gate/test-presence.test.ts: prose-with-DDL-keywords string literal → not query code (the Site#3539 line, verbatim); statement-shaped CREATE INDEX/CREATE TABLE/ALTER TABLE/DROP TABLE → still detected; a replay of Site#3539's file set (description-string edit + two spec files + 0 new hashes) → verdict null. Existing migration/DDL-in-source tests unchanged and passing. Full suite: 302 tests / 29 files green; tsc --noEmit clean.

🤖 Generated with Claude Code

[github-actions]

Query Doctor Analysis

3 queries analyzed

0 regressed · 0 improved · 0 new · 0 removed

2 pre-existing issues

• SELECT "guests"."id", "guests"."session_id", "guests"."username", "guests"."avatar_path", "guests"."color", "guests"."side", "guests"."audio_recording_path", "guests"."audio_recording_public", "gue...
  index assets(event_id, inserted_at desc)
  cost 31,003,449 → 1,498 (100% reduction)
• SELECT * FROM guest_ip_addresses WHERE ip_address = '127.0.0.1';
  index guest_ip_addresses(ip_address)
  cost 154,402 → 8 (100% reduction)

_{Using assumed statistics (10000000 rows/table). For better results, sync production stats.}

_{More detail → get_ci_run({ runId: "019f6205-7d9d-7583-9da1-cf0c2ae91ee8" }) · view run · docs}

[veksen]

Regression sweep: replayed the gate (old pattern vs this PR) over the last 40 Site PRs (#3512–#3570, 261 changed files, real pulls/N/files patch data). 39/40 classify identically; the only difference is Site#3539 — the false positive — which goes from dataAccessChanged: [packages/mcp-server/src/tools/index.ts] to clean. No PR gains a flag, none loses a legitimate one.