Remove anon from supabase_admin-owned default privileges on schema public

Goal: we have deliberately removed all anon access from schema public and rely only on authenticated and service_role. We want new objects to not be created with anon grants.

Problem: pg_default_acl has entries owned by supabase_admin for schema public that grant anon on every future object. Because they are owned by supabase_admin, our postgres role cannot revoke them (ALTER DEFAULT PRIVILEGES FOR ROLE supabase_admin ... requires membership of that role).

Reproduction (read-only):

SELECT n.nspname AS schema, pg_get_userbyid(d.defaclrole) AS owner_role,
       d.defaclobjtype AS obj_type, pg_get_userbyid((a).grantee) AS grantee,
       (a).privilege_type AS priv
FROM pg_default_acl d
JOIN pg_namespace n ON n.oid = d.defaclnamespace
CROSS JOIN LATERAL aclexplode(d.defaclacl) a
WHERE n.nspname = 'public' AND pg_get_userbyid((a).grantee) = 'anon';

Result (owner supabase_admin):

• tables: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER, MAINTAIN
• sequences: SELECT, UPDATE, USAGE
• functions: EXECUTE

What we have already done: revoked every existing anon grant on tables, functions and sequences in public (confirmed zero), and we revoke anon on each object we create. The residual is objects created by platform operations under supabase_admin, which are born open again.

What we already know: the usual guidance is "rely on RLS, don't worry about anon grants." We have made the stricter choice of removing anon entirely from public, so that answer does not fit our model. We are not asking about the graphql, graphql_public or storage schemas, which we understand are platform-managed.

Questions:

1. Is there a supported way for a project owner to remove the anon grants from the supabase_admin-owned default ACLs on schema public?
2. If not, is this default intentional, and is the per-object REVOKE the intended workaround?
3. After provisioning, does anything Supabase runs (extension installs, platform migrations) actually create objects in public under supabase_admin that would hit this default? Or is the surface in practice limited to objects we create ourselves?

Postgres 17.6, single project. Happy to share the project ref privately if a Supabase engineer needs it.