Supabase Postgres extensions: enable in a migration, not by hand in the dashboard

# Postgres extensions: migration-managed, not click-managed

Extensions like pgvector, pg_cron, pg_net, and pg_trgm change what your database can do. Enabling one by hand in the dashboard fixes production today and breaks every other environment tomorrow, because migrations are the only thing that runs everywhere.

## Checkable procedure

1. Write `create extension if not exists [name];` in a migration file. Commit it, review it, deploy it through the normal pipeline like any schema change.
2. Check the extension is available on your plan and Postgres version before depending on it. Not every extension is installable on every project; the docs list what is supported.
3. Be explicit about the schema when it matters. Some setups install extensions into a dedicated schema; unqualified function calls from other schemas then fail. Qualify or set search_path deliberately.
4. After enabling, verify in every environment: local, branch, staging, production. "Works locally" with a hand-enabled extension is the classic trap.
5. Treat extension upgrades like migrations: test on a branch first. A major version bump can change function signatures your code depends on.

## Quick test

Spin up a fresh local database, run migrations from zero, and confirm the extension-dependent code works. If it only works on databases where someone clicked the dashboard, the migration is missing.