The push gate never sees a new migration unless a human names it in a test: only terra_16 and terra_19 are read

A MIGRATION LANDS WITH NO GATE COVERAGE BY DEFAULT, AND ADDING ONE TO db/migrations/applied/ TRIGGERS NOTHING. Measured by coder-terra-cc 2026-08-16 while checking whether the pre-push suite would sweep another lane's untracked migrations. .gitpush-pre.sh itself carries ZERO migration references. The suite it runs does: src/lib/user-admin-core.test.ts:39-46 reads db/migrations/, but BY EXPLICIT FILENAME - applied/terra_16_... and applied/terra_19_... - never by walking the directory. THIS WAS FOUND BY A CORRECTION, WHICH IS WHY IT IS WORTH A ROW. coder warned that pushing while terra_26/27 sat untracked would exercise db-terra-cc's files under a coder WI. They then read the mechanism and reported themselves wrong: the files were never in scope. The real property is the opposite one and strictly worse - THE GATE NEVER SEES A NEW MIGRATION UNLESS A HUMAN NAMES IT IN A TEST. WHY IT MATTERS ON THIS PROJECT SPECIFICALLY: terra's migrations run against a SHARED clinical database co-tenanted with enamel, migrations are frequently applied to the live DB BEFORE the file reaches the repo, and terra derives replay order from the applied/ directory. So the artifact with the least automated scrutiny is the one with the largest blast radius, and the absence of coverage is silent - a suite that names two files out of the whole directory reports green exactly as loudly as one that walks it. Only terra_16 and terra_19 are named. Every other migration in applied/, including every one landed since, has never been read by any check at push time. SCOPE, and the design question is genuinely open - do not assume a directory walk is the answer: 1. Decide what a migration-level gate could honestly assert at push time. A walk that merely proves files parse is close to worthless; a walk that asserts every applied/ file corresponds to something actually applied would need DB access the pre-push suite does not have and should not acquire. 2. State explicitly what the check CANNOT cover, so the next reader does not credit it with more than it does. 3. If the honest answer is that no automated push-time gate is worth building here, record THAT as the outcome with its reasoning, and make the absence visible rather than leaving it to be rediscovered. 4. Whatever is built, it must not fire wrongly on terra-owned Class-S migrations - a bar that produces false refusals is a bar someone disables. Related standing bar (already adopted, do not duplicate here): newly recorded or materially amended applied migrations must cite their governing GO/PASS tags in-file, refused pre-apply and again pre-push. That covers AUTHORIZATION. This row is about COVERAGE, and the two are independent.