db: Prisma-Migrations-System statt db push (datenerhaltend)

`db push --accept-data-loss` konnte bei Schema-Änderungen still Daten verlieren
(Renames, Type-Changes, NOT NULL ohne Default). Umstellung auf versionierte
Migrations:

- 0_init aus aktuellem Schema generiert (alte gedriftete Migrations entfernt)
- entrypoint: Auto-Baseline für bestehende DBs ohne `_prisma_migrations`,
  dann `migrate deploy` (idempotent, kein Daten-Loss)
- npm run schema:sync: legt automatisch eine Migration mit Zeitstempel an
  (`prisma migrate dev --name auto_<ts>`)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/todo.md

@@ -97,6 +97,22 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🗃️ Prisma-Migrations-System (statt `db push`)**
+  - Initial-Migration `0_init` aus aktuellem Schema generiert
+    (`prisma migrate diff --from-empty --to-schema-datamodel`).
+  - 24 alte gedriftete Migrations gelöscht – frischer Start.
+  - `migration_lock.toml` für MySQL hinzugefügt.
+  - Container-Entrypoint umgebaut:
+    - Auto-Baseline-Detection: bestehende DB ohne `_prisma_migrations` →
+      `migrate resolve --applied 0_init` läuft automatisch.
+    - Statt `db push --accept-data-loss` jetzt `migrate deploy` (idempotent,
+      datenerhaltend, keine stillen DROPs mehr).
+  - Neuer npm-Script `schema:sync` (lokal/Dev): legt automatisch eine
+    versionierte Migration mit Zeitstempel-Namen an
+    (`prisma migrate dev --name auto_$(date +%Y%m%d_%H%M%S)`).
+  - Workflow ab jetzt: schema.prisma ändern → `npm run schema:sync` →
+    Migration committen → Push → Container-Restart wendet sie automatisch an.
+
 - [x] **🔄 Automatische Vertrags-Status-Übergänge**
   - Nightly-Cron (02:00 + Catch-up 60s nach Start): alle Verträge mit
     `status=ACTIVE` und `endDate < heute` → `EXPIRED` (mit Audit-Log).