feat(260924-m4n): Bilderrahmen Stufe 2 - alte Bildspalte data entfernt, storagePath Pflicht

- Migration 20260924120000_dashboard_image_drop_data: Schutzpruefung
  (bricht ab, solange eine Zeile ohne storagePath existiert; row_security
  aus, damit ein Eigentuemer ohne BYPASSRLS nicht still 0 Zeilen sieht),
  dann NOT NULL, DROP COLUMN data, DROP POLICY system_read_policy
- Dienst: Bootstrap-Umzug samt forSystem() und Selbstheilung aus data
  entfernt; Upload vergibt die UUID selbst, Zeile gleich mit Pfad
- FORSYSTEM_ALLOWED_CALL_SITES, Tests, Zugriffsklassifikation (per
  Gate-Schleife gemessen: 61/213/6) nachgezogen
- Betriebshandbuch Kap. 4: Hinweis und Wiederherstellungsweg bei Abbruch
- Todo 2026-09-22 nach completed/

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

docs/anleitung-betrieb.md

@@ -221,6 +221,35 @@ der `.env` als `IMAGE_TAG` steht, siehe Kapitel 9.)
 sie auf dem Server abweichen.) Liegt `StartedAt` **vor** `Created` des Images, läuft
 noch die alte Version – dann `--force-recreate` nachholen.
 
+**Hinweis für die erste Version nach 1.3.1 – alte Bildspalte fällt weg:** Diese
+Version entfernt die alte Spalte, in der die Bilder des Bilderrahmen-Widgets
+früher in der Datenbank lagen (Migration `20260924120000_dashboard_image_drop_data`).
+Die Bilder selbst liegen seit 1.3.1 im Volume `user-files`; 1.3.1 hat sie beim
+ersten Start von selbst dorthin umgezogen. Hat ein Server 1.3.1 übersprungen, wäre
+der Umzug dort nie gelaufen – dann bricht die Migration ab, **bevor** sie etwas
+ändert, und der `api`-Container startet nicht. In `docker compose logs api` steht
+dann die Meldung „DashboardImage: es gibt noch Zeilen ohne storagePath — Umzug
+(quick-260922-hk4) zuerst mit einer Version >= 1.3.1 laufen lassen, dann erneut
+deployen“. Es gehen dabei keine Bilder verloren. Abhilfe in drei Schritten:
+
+1. Den abgebrochenen Versuch als zurückgenommen vermerken – sonst verweigert
+   auch 1.3.1 jeden Start, weil Prisma eine fehlgeschlagene Migration in der
+   Datenbank sieht (Fehler `P3009`):
+
+   ```bash
+   docker compose -f docker-compose.prod.yml exec db \
+     psql -U tessera -d tessera -c \
+     "UPDATE _prisma_migrations SET rolled_back_at = now() WHERE migration_name = '20260924120000_dashboard_image_drop_data' AND finished_at IS NULL;"
+   ```
+
+2. In der `.env` `IMAGE_TAG=v1.3.1` setzen, `pull` und `--force-recreate` wie
+   oben, den Start abwarten – der Umzug läuft dabei von selbst.
+3. `IMAGE_TAG` zurück auf den Kanal (`live` bzw. `beta`) und erneut einspielen;
+   jetzt läuft die Migration durch.
+
+(Dieser Ablauf ist am 24.09.2026 in einer Wegwerf-Datenbank vollständig
+durchgespielt.)
+
 ## 5. Datenbank-Migrationen
 
 Ein separater Migrationsschritt ist **nicht** nötig. Der `api`-Container führt