FDN-02/FDN-03/FDN-07/FDN-08: Migrations-Rollback, Objekt-Storage-Interface, go.sum-Fix, Observability

- FDN-02: Rollback-fähige Down-Migrationen (024-026), archivdms seed dev CLI
- FDN-03: internal/objectstore Interface + lokaler WORM-Treiber, signierte Download-URLs
- FDN-07: go.mod/go.sum vervollständigt (fehlender go-ldap/v3-Eintrag), CI-Pipeline (.gitea/workflows/ci.yml, bereits in FDN-01 committet) damit lauffähig
- FDN-08: Request-ID-Middleware, /metrics-Endpoint, Panic-Recovery, Login/Logout/Me technisches Logging inkl. Access-Log je Anfrage

internal/storage/migrations/README.md

@@ -23,6 +23,45 @@ Migrationstool. Sie dient als:
 3. Der SQL-Inhalt muss exakt dem entsprechen, was `initSchema()` (oder das
    jeweilige Store-Paket) zur Laufzeit ausführt.
 4. Migrationen werden nie verändert oder gelöscht, nur ergänzt.
+5. **Zu jeder neuen Migration gehört eine Down-Datei** `NNN_name.down.sql`
+   (siehe Abschnitt „Rollback-Pfad").
+
+## Rollback-Pfad (`NNN_name.down.sql`)
+
+`initSchema()` ist ausschließlich vorwärtsgerichtet — es gibt bewusst keinen
+automatischen Rollback-Runner (kein Migrationstool, kein Zustandstabellen-
+Tracking). Für den Ernstfall (fehlerhaftes Release, Rückbau eines Features)
+braucht es trotzdem ein *reviewtes* Rückbau-SQL. Deshalb gilt ab FDN-02:
+
+**Jede neue `NNN_name.sql` bekommt eine gleichnamige `NNN_name.down.sql`**
+mit dem exakten Rückbau der Vorwärts-Migration. Separate Datei statt
+`-- DOWN`-Abschnitt in derselben Datei, weil Regel 4 („Migrationen werden nie
+verändert") sonst verletzt würde und weil sich eine Down-Datei fehlerfrei
+per `psql -f` einspielen lässt, ohne vorher Abschnitte herauszuschneiden.
+
+Anforderungen an eine Down-Datei:
+
+1. Header-Kommentar mit Bezug auf die Vorwärts-Migration und der zugehörigen
+   PROJ-/Ticket-Nummer.
+2. **Precondition** benennen: welche Go-Stelle (`initSchema`, Store-Datei,
+   aufrufende Queries) vorher entfernt bzw. deployt sein muss. Sonst legt der
+   nächste Prozessstart das Objekt sofort wieder an.
+3. **Datenverlust explizit benennen** — was ist danach unwiederbringlich weg,
+   was ist regenerierbar (z.B. abgeleitete Indizes wie `ocr_words`).
+4. **WORM/GoBD-Hinweis**: klarstellen, dass kein archiviertes File unter
+   `store/` und kein `retain_until` berührt wird. Down-SQL darf niemals
+   Dokument-Nutzdaten oder Aufbewahrungssperren löschen.
+5. Idempotent formulieren (`DROP ... IF EXISTS`) und in `BEGIN; ... COMMIT;`
+   klammern.
+
+Ausführung ist immer **manuell und bewusst** (`psql -f
+internal/storage/migrations/NNN_name.down.sql`), nie automatisch beim Start.
+
+Beispiele (rückwirkend ergänzt, dienen als Vorlage):
+`024_ocr_words.down.sql`, `025_document_date_score.down.sql`,
+`026_accounting_api_keys.down.sql`. Ältere Migrationen (001–023) haben keine
+Down-Datei — sie beschreiben das etablierte Kernschema, dessen Rückbau kein
+realistisches Szenario ist.
 
 ## Vorhandene Migrationen