Security: migrate internal edge function auth to Supabase Vault

[aultra]

Summary

Internal edge functions called from DB triggers/cron jobs via pg_net currently use verify_jwt = false (no authentication). This works but means anyone who discovers the function URL could call it.

Scope

Evaluate all edge functions and database functions for auth posture — not just the ones currently using verify_jwt = false. This should be a comprehensive security audit covering:

• Functions called from DB triggers/cron (currently no auth)
• Functions called from the client (JWT or service_role auth)
• Functions exposed to external webhooks (sms-webhook, gmail-inbound, etc.)
• Database functions with SECURITY DEFINER that may need tighter access control

Known Functions Using verify_jwt = false

• process-notification-push (DB trigger on notifications INSERT)
• gmail-watch-renew (daily cron)
• check-lead-warnings (cron)
• process-lead-scheduled-messages (cron)
• sms-webhook, gmail-inbound, call-webhook (external webhooks)
• request-access, accept-invitation, validate-invitation (public registration flow)
• contact-form-webhook, testflight-webhook

Proposed Solution

Migrate to Supabase Vault for secure secret storage where appropriate:

1. Store a dedicated internal API key in Vault
2. Retrieve it at runtime in trigger/cron SQL: SELECT decrypted_secret FROM vault.decrypted_secrets WHERE name = 'internal_api_key'
3. Pass as Authorization header in pg_net calls
4. Add auth validation to each internal edge function
5. Remove verify_jwt = false where possible
6. For external webhooks, evaluate per-function (e.g., OpenPhone signature verification for sms-webhook)

References

• Supabase Scheduling Docs — recommends Vault for trigger/cron auth
• Discussion #9242 — community patterns for passing secrets
• Discussion #22113 — restricting edge functions to internal callers

Priority

Low — current approach matches existing project patterns and works. This is a hardening improvement for a future security pass.