Squash the 30 EF migrations into a single InitialCreate before first production deploy #245

This was generated by AI during triage.

Split from the deployment-readiness audit (#244, "Migrations" checklist item).

Problem

src/Cluckwork.Infrastructure/Persistence/Migrations/ holds 30 migrations, and Database:MigrateOnStartup replays all of them on every fresh database. 12 of them contain raw SQL / data operations (ConvertLotsAndSalesToEggGradeIds, AddBirdMovementEntryRefAndBackfill, backfills in expenses/product-catalog/inventory, …) that were written for mid-history data states. On an empty database they touch 0 rows, but they still execute — a first production deploy runs three weeks of schema archaeology instead of one clean CREATE pass.

Proposal

Squash to a single InitialCreate generated from the current model, before the first real-world deploy:

1. Delete the Migrations/ folder (including *.Designer.cs and the model snapshot).
2. dotnet ef migrations add InitialCreate → one migration + fresh snapshot.
3. Verify: dotnet build clean, integration tests green (Testcontainers spins a fresh Postgres and exercises the new migration end-to-end).

Why now

• No production database exists yet. After go-live, squashing requires baselining every deployed DB's __EFMigrationsHistory; today it costs nothing there.
• Fresh deploys (and every Testcontainers run) apply one migration instead of 30 — faster startup, and none of the mid-history backfill SQL runs against production.

Impact on existing databases

Any DB that already has rows in __EFMigrationsHistory (local dev DB from deploy/docker-compose.dev.yml, any demo instance) will fail MigrateOnStartup after the squash — the old history names no longer match. These are disposable: drop and recreate (docker compose -f deploy/docker-compose.dev.yml down -v && up -d). Call this out in the PR description.

Acceptance

• Single InitialCreate migration; schema identical to the pre-squash snapshot (integration suite green).
• Fresh docker compose -f deploy/docker-compose.yml up --build boots, seeds, and runs the egg loop.
• PR notes the dev-DB drop/recreate step.
• Must land before the first production deploy (Deployment readiness audit: production go-live scan before first real users (host undecided) #244 blocks on it or records it as done).