novahiz-supabaselisted

# novahiz-supabase Production Supabase work: Auth, RLS, Edge Functions, Storage, and the operations around them. ## Core principles ### Verify against the changelog before you implement Supabase moves quickly. Signatures, `config.toml` keys, and API conventions change between releases. Fetch `https://supabase.com/changelog.md`, scan for `breaking-change` tags that touch your task, follow the linked pages that apply, then look up the topic in the docs below. Training data is not a substitute. ### Prove the fix After any change, run a query that shows it works. An unverified fix is unfinished work. ### Stop after two or three failures If an approach keeps failing, change method instead of looping. Re-read the error, check the docs, look at logs when they exist. ### Authorization lives in the database Supabase is raw Postgres underneath. Put the rules in RLS rather than scattering them across clients. ## Security checklist ### Auth and sessions 1. Never authorize from `user_metadata`. In Supabase, `raw_user_meta_data` is user-editable and surfaces in `auth.jwt()`, so it is unsafe for RLS or any other decision. Put authorization data in `app_metadata` / `raw_app_meta_data`. 2. Deleting a user does not kill live access tokens. Sign out or revoke sessions first, keep access token expiry short on sensitive apps, and on critical paths check `session_id` against `auth.sessions`. 3. Claims from `app_metadata` or `auth.jwt()` stay stale until the token refreshes. Plan for t