feat(v3-ref-seller): replace Base.metadata.create_all with Alembic migrations (cross-link #382)

[bokelley]

Context

Base.metadata.create_all is idempotent on table existence but silently misses column renames and type changes. Adopters who pulled mid-rename during the recent broadening cycle hit NULL bugs because existing tables weren't altered.

Acceptance Criteria

• Alembic scaffold lands in examples/v3_reference_seller/ (cross-link feat(v3-ref-seller): Alembic migration scaffold replacing Base.metadata.create_all #382)
• Base.metadata.create_all replaced with alembic upgrade head on boot
• Until Alembic lands, README has a clear "drop the dev DB on schema changes" warning

Refs

• Existing feat(v3-ref-seller): Alembic migration scaffold replacing Base.metadata.create_all #382 (Alembic scaffold)
• v3 ref seller broadening cycle (PR feat(v3-ref-seller): broaden sales surface + sync_accounts + invoice_recipient #408)

[bokelley]

Triage

Classification: Feature request
Bucket(s): examples
Status: deferred (fold candidate — blocked on PR #390)

Context read:

• PR docs(examples): Alembic migration scaffold for v3 reference seller #390 (claude/issue-382-alembic-migration-scaffold, draft, open) already implements the Alembic scaffold for feat(v3-ref-seller): Alembic migration scaffold replacing Base.metadata.create_all #382. Its initial migration covers the 5 pre-broadening tables: tenants, buyer_agents, accounts, media_buys, audit_events.
• PR feat(v3-ref-seller): broaden sales surface + sync_accounts + invoice_recipient #408 (merged ~30 min before this issue was filed) added three schema items not covered by PR docs(examples): Alembic migration scaffold for v3 reference seller #390's migration: Creative table, PerformanceFeedback table, and MediaBuy.invoice_recipient column.
• Criterion chore(main): release 0.1.2 #3 ("drop the dev DB" warning) is already present in README.md lines 150–156 under "What's NOT wired." No additional action needed there.

My take: The entire Alembic scope here belongs in PR #390 — updating the initial migration (or adding a second migration) to cover the broadening-cycle schema additions before that PR merges. Folding is better than a follow-up PR because the migration file is contiguous and the Alembic history would be cleaner with one initial migration that reflects the actual current schema.

Blocked-on: #390 — resurfaces on merge. Commenting on #390 now to surface the gap.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_015VqV8vGd49wgLG3HPGch3F

---

Generated by Claude Code