Set up reproducible local Supabase database, migrations and seed

[linear]

Sprint

Planned for Sprint 6, beginning 7 September 2026. This is not Sprint 5 delivery.

Goal

Make a clean clone reproducibly start ShowCrafter against a local Supabase stack without production data or undocumented manual steps.

Scope

• Add and commit supabase/config.toml with local-safe settings and no secrets.
• Audit local migration order against the linked project's migration history before changing it.
• Resolve migration-history gaps deliberately, preserving forward-only production history.
• Consolidate deterministic development seed data using supabase/seed.sql or ordered seed paths in config.toml.
• Seed only synthetic users and useful catalogue, assortment, show and credit scenarios.
• Regenerate lib/database.types.ts from the verified local schema.
• Add a concise local database runbook to the handover documentation.

Acceptance criteria

• supabase start succeeds from the repository root.
• supabase db reset applies every migration in order and then seeds without manual intervention.
• A second reset produces the same usable development state.
• Local auth, catalogue, assortment QR, My Store and generation paths have representative synthetic data.
• Exposed tables retain intentional grants, RLS and policy coverage.
• Database tests and the application's focused checks pass against the local schema.
• Local and linked migration histories are compared and any mismatch is documented before repair or deployment.
• No production customer data, passwords or service-role secrets enter the seed.

Current repository boundary

The repository already contains migrations and several standalone seed SQL files, but it has no committed supabase/config.toml or canonical supabase/seed.sql. The README mentions a local Supabase environment but does not yet provide a reproducible reset workflow.