terra_22 asserts trigger identity by tgname with no tgrelid scoping, so the assertion can match a trigger on another relation

FOUND 2026-08-17 by db-terra-cc while fixing audit finding (b) on terra_29, and filed rather than fixed in passing because it is a different migration. terra_22 asserts trigger identity by tgname ONLY, with no tgrelid scoping. A tgname-only match can select rows on other relations, so the assertion can be satisfied by a trigger that is not the one the migration created. terra_29 was corrected in-file to also scope tgrelid = the target relation::regclass; terra_22 was deliberately NOT touched in that change. This is an ASSERTION-STRENGTH gap, not a known-wrong result: terra_22 is applied and there is no evidence its assertion matched the wrong row. Measure before writing anything - if the assertion happens to be unambiguous on the live catalog, the fix is to strengthen the pattern for future migrations, not to re-assert history. Do NOT re-run or amend an applied migration to fix this. Per terra post-apply amendment rule, an applied file takes comment-only edits. Any real remedy is a new migration or a change to the pattern used by the next one. Same family as every other terra entry where a check returns a true answer to a narrower question than the one asked - here, does a trigger with this NAME exist, not does THIS trigger on THIS table exist.