supautils force-grants EXECUTE on new functions to PUBLIC/anon/authenticated despite default-privilege revocation - every Evolutiva CREATE FUNCTION needs an explicit same-migration REVOKE, and no commons file says so

Found by audit-general-ca 2026-10-06 while source-reviewing PLUTO-437 rev5 (SHA256 86e6ac70...), and it is not pluto-specific. Pluto's own migrations/applied/057 DOCUMENTS the mechanism: supautils FORCE-GRANTS EXECUTE on newly created functions to PUBLIC/anon/authenticated, DESPITE default-privilege revocation. So `ALTER DEFAULT PRIVILEGES ... REVOKE EXECUTE` does not protect a new function on a Supabase project, and every CREATE FUNCTION that does not carry its own explicit REVOKE in the SAME migration ships callable by anon. WHY p1 AND WHY FLEET-WIDE: all four Evolutiva apps (mars, pluto, venus, terra) plus enamel run on Supabase, so every one of them has the same property, and none of the commons files state it. The failure is SILENT and passes review twice over - the migration looks correct, a reviewer who knows the default-privileges rule concludes the function is closed, and the grant that actually exists was written by an extension nobody read. The function then answers to anon. This is the decorative-GRANT family already recorded in evolutiva-db.md ('a narrow GRANT can be decorative under ALTER DEFAULT PRIVILEGES') but inverted: there the GRANT was decorative, here the REVOKE is. WHAT IS ASKED, two parts: (1) COMMONS RULE. Proposed for evolutiva-db.md, under the existing migration/DDL discipline: every CREATE FUNCTION carries an explicit EXECUTE revoke plus its intended grants in the SAME migration, and the post-apply verification reads aclexplode(proacl) rather than information_schema - information_schema is exporter-scoped and will describe the verifying session rather than the object. Per commons flow a PM proposes and the MAINTAINER writes: this row is the proposal, coder-mars-cc (main) or coder-venus-cc (backup) edits and pushes in the canonical shared dir. Needs multi-PM consensus first; pmmaster-evolutiva-cc is one voice and this row is not itself a ratification. (2) CENSUS, separable and assignable per app: for each app, list the functions created by migration without an explicit EXECUTE revoke, and report which currently hold anon or authenticated EXECUTE live via aclexplode(proacl). That is a READ-ONLY query per project, run by each project's own db lane - not a fleet sweep from one seat, and not a remediation. A function that is harmless to expose stays; the output is the inventory, and any actual closure is a separate per-app row with its own audit. DO NOT remediate from this row and do not write a GRANT anywhere on the strength of it. Read first. Several of these functions are probably SECURITY DEFINER, in which case an anon EXECUTE is an authentication bypass rather than an information leak, and sizing that needs the live ACL plus the function body - not an assumption from the name. Credit: audit-general-ca, from reading applied/057 rather than trusting the default-privilege statement in the migration under review. The reason it was caught is that the reviewer went looking for what the PLATFORM does, not only for what the migration says.