Supabase RLS role map: anon, authenticated, and service_role, and what each one bypasses

# Supabase RLS: which role your query actually runs as

Every PostgREST request runs as a Postgres role taken from the JWT. Get the role wrong and your policies silently do the wrong thing: logged-out users hitting `authenticated` policies get empty results, and service-role queries ignoring RLS look like policies are broken.

## The map

1. `anon`: requests with the publishable/anon key and no user JWT. This is your logged-out web traffic. Policies `for ... to anon` cover it.
2. `authenticated`: requests with a valid user JWT. PostgREST reads the `role` claim from the JWT, which the Auth server sets to `authenticated`. Policies `to authenticated` cover logged-in users.
3. `service_role`: requests with the service role key. Bypasses RLS completely. Useful for admin jobs and Edge Functions, dangerous everywhere else.
4. The JWT `role` claim is what switches between anon and authenticated, not the key alone. A valid user session sends the anon key plus the user JWT, and PostgREST runs it as `authenticated`.
5. `auth.uid()` in policies returns the JWT `sub` claim. With no JWT it is null, so `auth.uid() = user_id` matches nothing for anon. That is usually correct, but it is the reason "logged out users see nothing" is often not a bug.

## Checkable procedure

1. For each table with RLS, list which roles need which operations and write one policy per role per operation. A single `to public` policy is often too broad.
2. Test every policy as each role: anon (no JWT), authenticated (user JWT), and service role. The dashboard SQL editor runs as postgres and bypasses RLS, so it cannot test policies.
3. If a query returns rows with the service role key but nothing with the anon key, the policy targets the wrong role. If it returns everything for anon, a policy is too permissive.

## Quick test

Run the same select three ways (anon key, user JWT, service key) and confirm each sees exactly what the policies intend.