-- Explicit schema/table/sequence/routine grants for anon/authenticated/
-- service_role.
--
-- Found while standing up a local Supabase instance to run the integration
-- test suite (spec §17): every table in this schema
-- relies on RLS policies to restrict access, but RLS only ever *narrows*
-- what an already-GRANTed role may do — Postgres still checks ordinary
-- object privileges first, independent of a role's BYPASSRLS flag. On
-- Supabase's hosted platform this GRANT setup is applied automatically
-- during project provisioning, so it was invisible here: every previous
-- migration worked fine against the already-provisioned hosted project, but
-- the exact same migrations against a *fresh* Postgres (a new local dev
-- instance, a disaster-recovery restore, or CI) fail with "permission
-- denied for table X" even for the service role, since that grant was never
-- actually part of this repo's own migrations. Making it explicit here
-- makes the schema fully self-contained and reprovisionable from scratch.
grant usage on schema public to anon, authenticated, service_role;

grant all on all tables in schema public to anon, authenticated, service_role;
grant all on all sequences in schema public to anon, authenticated, service_role;
grant all on all routines in schema public to anon, authenticated, service_role;

alter default privileges in schema public grant all on tables to anon, authenticated, service_role;
alter default privileges in schema public grant all on sequences to anon, authenticated, service_role;
alter default privileges in schema public grant all on routines to anon, authenticated, service_role;