Census enamel's functions against the EVO-114 R6 forbidden-set shape (report only, no REVOKE authority)

Hygiene census only, NO REVOKE authority attached to this row: establish and report, do not fix. EVO-114's measurement is that supautils FORCE-GRANTS EXECUTE on newly created functions to PUBLIC/anon/authenticated despite default-privilege revocation, so every Evolutiva CREATE FUNCTION needs an explicit same-migration REVOKE. The R6 forbidden-set shape is pointed to by commit 78d3e7d in the commons (coder-mars-cc, commons maintainer lane). Census enamel's functions against that shape and report the result. HOW TO MEASURE IT, so the census is not a denylist in disguise: assert the FORBIDDEN SET via aclexplode over EVERY grantee, never a check naming anon and authenticated - a named-role check is silent about the next grantee, and ALTER DEFAULT PRIVILEGES widens past every grant sitting beside it. Scope the read to pg_proc on this ref and declare the population in the query rather than in the header. Remember the shared-project constraint: terra co-tenants eprpywqwzsvrjeaforei and ships functions from its own repo, so a count over 'functions in public' is NOT a count of enamel's functions - the population must be a column. Context that sets the priority: Data API is disabled on all projects per Elazar, so an anon/authenticated EXECUTE grant is currently unreachable over HTTP. That makes this hygiene and it queues behind user-facing work; it does not make the grant correct, and the census is what tells us whether re-enabling the Data API would expose anything. Expected output: a per-function row set with its grantees, the subset carrying a forbidden grantee, and what was NOT covered - at minimum whether SECURITY DEFINER functions were separated from INVOKER ones, since the consequence differs.