docs: Migrationsausfall nachgestellt und Notfallweg dokumentiert

Marcs Sorge ernst genommen und geprüft statt behauptet: eine
absichtlich kaputte Migration in einer Wegwerf-Datenbank laufen lassen.
Ergebnis: schema_migrations bleibt auf dirty=true stehen, und main.go
bricht bei jedem weiteren Start mit log.Fatal ab – das gilt für jede
Migration, nicht nur die des Kalenders, und stand schon vorher so im
Code.

Drei Sicherungen vor der ersten Kalendermigration: nur CREATE TABLE IF
NOT EXISTS (idempotent, nie ALTER an Fremdem), erst auf der Dev-Instanz
hoch und runter, ein pg_dump vor dem ersten produktiven Ausrollen.

Die Notfallzeile (UPDATE schema_migrations SET dirty=false) steht jetzt
ganz oben in TESTING.md – nicht nur für den Kalender, für jede künftige
Migration.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TESTING.md

@@ -9,6 +9,29 @@ Manuelle Test-Checkliste für die fertigen Phasen. Abhaken beim Durchtesten.
 
 ---
 
+## Notfall: Migration hängt fest ("Dirty database version")
+
+Betrifft jede künftige Migration, nicht nur eine bestimmte. Nachgestellt und
+bestätigt (siehe kalender-plan.md, Abschnitt „Migrationen"): Scheitert eine
+Migration, bleibt `schema_migrations.dirty` auf `true` stehen, und **jeder**
+weitere Start von Aether bricht ab – die ganze Cloud, nicht nur der neue Teil.
+
+Kein Datenverlust dabei: Die Migration lief in einer Transaktion und wurde
+zurückgerollt, bevor der Fehler kam. `dirty=true` ist nur eine Sperre, keine
+Aussage über beschädigte Daten.
+
+Beheben:
+
+    docker exec aether-db psql -U aether -d aether \
+      -c "UPDATE schema_migrations SET dirty=false;"
+
+Danach Aether neu starten. Lief die Migrationsdatei nur teilweise (z. B. zwei
+`CREATE TABLE` in einer Datei, das erste gelang), vorher prüfen, was bereits
+existiert, bevor man einen erneuten Lauf zulässt – sonst scheitert der zweite
+Versuch am selben Fehler wie der erste.
+
+---
+
 ## Phase 3 – Admin, Gruppen, Theming, Profil
 
 ### Admin-Panel: Zugriff & Sicherheit