Revoke PUBLIC and anon EXECUTE on internal schema helpers #469

Summary

Revoke EXECUTE from PUBLIC and anon on the internal schema helpers that no anon policy needs.

• Why now: Make a Private document's chat readable and writable only by its owner #396 (migration 20261008130000) granted anon USAGE on schema internal, so anon policies can call internal.can_open_document. Every other function in internal still keeps the default PUBLIC EXECUTE. That includes is_workspace_member, is_channel_member, can_read_channel, and several notification and user helpers.
• Exposure today: none that we know of. PostgREST and GraphQL do not expose internal. This is defense in depth.
• Why it was not part of Port the 2026-09-28 prod grant and RLS fix into scripts and a paired migration #314: Port the 2026-09-28 prod grant and RLS fix into scripts and a paired migration #314's migration promised to change nothing on prod. This change does.

Fix

1. List every function in internal and its callers: pg_policies qual and with_check, storage policies, and invoker bodies that clients reach.
2. Keep anon EXECUTE only on internal.can_open_document. Keep authenticated only where an authenticated policy calls the function. Grant service_role where a server path calls it.
3. Revoke the rest from public, anon, authenticated, in the owning scripts and in one new migration. Regenerate seed.sql.
4. Prove a fresh reset: anon reads a public chat; the owner reads a Private chat; a signed-in send works.

Acceptance

• Each kept grant names its policy or caller in the PR.
• has_function_privilege for anon is false on every internal function except can_open_document.
• The migration is applied to prod, with a read-only check posted here.