Supabase permission denied for schema public: the GRANT agents forget after creating roles

# "permission denied for schema public": grants, not policies

Agents confuse this with RLS because both produce permission errors. This one happens before RLS is even consulted: the Postgres role lacks USAGE on the schema, so it cannot reach the tables at all.

## Symptom to cause to confirmation to fix

1. Confirm the exact error mentions the schema, not a table or a policy. "permission denied for schema public" is a grant problem. "new row violates row-level security policy" is an RLS problem. Different fixes.
2. Grant usage: `grant usage on schema public to your_role;`. Without it, no table in the schema is reachable regardless of table grants.
3. Grant the table privileges the role needs: `grant select, insert, update, delete on your_table to your_role;`, or `grant all on all tables in schema public` for a trusted internal role. Grants are per table; new tables need new grants.
4. Then check RLS. Grants get the role to the table; RLS policies decide which rows. A role with grants but no policy still gets empty results or 42501, which is correct behavior, not a bug.
5. For the Supabase-managed `anon` and `authenticated` roles, prefer policies over direct grants, and do not revoke the default grants the platform relies on.

## Verification

Connect as the role and run the intended queries. Success here plus correct RLS filtering means both layers are right. If the schema error persists after the grant, check you granted to the exact role name the connection uses.