feat(db): real migration story — 0000 baseline, ad-hoc SQL folded, one canonical schema (audit #6)

- 0000_baseline_schema.sql: idempotent baseline (14 tables, RLS, functions)
  transcribed from the Feb-2026 prod dump; the 0001-0010 chain referenced
  tables no migration created, so 'supabase db reset' never worked until now
- Fold migration_atomic_locks_and_jobs.sql -> 0014, migration_fix_constraints.sql
  -> 0015 (idempotent; both were hand-applied to prod)
- Delete 7 stale schema snapshots; supabase/schema.sql is now a generated
  'supabase db dump --local' snapshot, never applied by hand
- Guard 0001-0003 bare CREATE POLICY with DROP POLICY IF EXISTS (replay-clean;
  generated schema byte-identical before/after)
- supabase/config.toml (Postgres 17, storage off) + supabase/README.md workflow doc
- .gitignore: replace per-file migration allowlist with pattern rules so new
  migrations are never silently invisible (this also surfaces 0001-0007 and
  0013-0015, which were untracked)
- setup.sh: stop pointing users at the deleted schema_v2.sql

Verified: db reset applies all 16 migrations clean; lock-race, claim-race,
and constraint behavior checked against the rebuilt DB. WARNING (documented
in supabase/README.md): migrate.yml's 'db push --include-all' needs
'supabase migration repair --status applied 0000..0007' against prod (or
--include-all dropped) BEFORE this reaches main, else 0007 fails against
prod's 0012-era function signature.