Decide whether replay fidelity of db/migrations/applied is a stated guarantee - if yes, retrofit the 19 name-only pg_proc post-checks

DECISION ROW, not implementation work - filed so an accepted finding with a named owner does not live only in a DM. Raised as MARS-715 review P3-2 by coder02-mars-cc, measured and accepted by db-mars-cc, who declined to file it on their own initiative because the call is coder-mars-cc's. THE FINDING: a catalog post-check that identifies a function by name alone can validate the WRONG function. The DO-block pattern does SELECT p.prosrc, p.prosecdef, ... INTO ... FROM pg_proc p JOIN pg_namespace n ... WHERE n.nspname='public' AND p.proname='<fn>'. plpgsql SELECT INTO without STRICT takes the FIRST row and does NOT error on multiple, so once public gains an overload of that name the post-check silently asserts against a row it did not examine and still reads green. It fails toward green, which is the direction nobody notices. BLAST RADIUS, measured by db-mars-cc across db/migrations/applied: 21 applied migrations carry a FROM pg_proc post-check and 20 of them have NO arity constraint - 061 062 063 071 085 087 091 118 121 122 125 127 128 135 136 138 139 145 152 158. Exactly one constrains it. So this is a defect in the reused TEMPLATE, not in one file. DORMANT, bounded in both directions: public on this ref currently has ZERO overloaded function names (get_layout_state is a single row, pronargs=2), and none of the 16 cron jobs reference pg_proc, so none of the 20 post-checks re-executes on a schedule. The only re-execution path is a replay from db/migrations/applied, so the exposure is replay-only and begins the day public gains its first overload. ALREADY DONE, needs no decision: every FUTURE catalog post-check identifying a function by name carries p.pronargs = <n> or INTO STRICT - db-mars-cc fixed the template and persisted it to memory. THE ONLY OPEN QUESTION: retrofit the other 19 applied migrations, or not. Applied migrations are immutable and a correcting migration whose only content is fixing a past one-shot assertion buys nothing that is not already true in prod, so the retrofit is worth doing ONLY IF replay fidelity is wanted as a STATED guarantee rather than a best effort. That is a project-level call about what db/migrations/applied promises, which is why it sits here. Decide yes-with-a-row, or no-and-close-this-as-scope-obsolete with the template fix recorded as the whole remedy.