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/024_ocr_words.down.sql

@@ -0,0 +1,27 @@
+-- 024_ocr_words.down.sql
+-- Rollback documentation for 024_ocr_words.sql.
+-- Documentation only — archivdms has no migration runner; run manually via
+-- psql after deploying a binary whose initSchema no longer creates the table.
+--
+-- PRECONDITION: Store.initOCRWordsSchema must be removed from
+-- Store.initSchema (internal/storage/documents.go) and every caller of
+-- ReplaceOCRWords / the word-box read path must be gone first — otherwise
+-- the next process start recreates the table.
+--
+-- DATA LOSS: ocr_words is a DERIVED index over each document's OCR run, not
+-- an original record. Dropping it loses no GoBD-relevant data; the word boxes
+-- are fully regenerable by re-running OCR
+-- (`archivdms documents reprocess-all`). Only the highlight/overlay feature
+-- degrades until then.
+--
+-- WORM: no archived file in store/ is touched; the FK to documents is only
+-- consumed here (ON DELETE CASCADE), never the other way round, so dropping
+-- this table cannot cascade into documents.
+
+BEGIN;
+
+DROP INDEX IF EXISTS idx_ocr_words_word_text;
+DROP INDEX IF EXISTS idx_ocr_words_document;
+DROP TABLE IF EXISTS ocr_words;
+
+COMMIT;

internal/storage/migrations/025_document_date_score.down.sql

@@ -0,0 +1,25 @@
+-- 025_document_date_score.down.sql
+-- Rollback documentation for 025_document_date_score.sql.
+-- Documentation only — archivdms has no migration runner; run manually via
+-- psql after deploying a binary whose initSchema no longer adds the column.
+--
+-- PRECONDITION: the ALTER TABLE ... ADD COLUMN IF NOT EXISTS
+-- document_date_score must be removed from Store.initSchema
+-- (internal/storage/documents.go) first, and every SELECT/UPDATE naming
+-- document_date_score (accounting_pull.go, document date endpoint) must be
+-- gone — otherwise the next start recreates the column and running queries
+-- fail in between.
+--
+-- DATA LOSS: drops the per-document confidence values. documents.document_date
+-- itself is NOT touched, so no belegdatum is lost — only the quality signal
+-- the Buchhaltungs-Pull-Filter (score >= 0.75) uses. Recomputable only by
+-- re-scoring the stored ocr_text.
+--
+-- WORM: this is a metadata column on documents; dropping it does not touch
+-- any archived file in store/ and does not affect retain_until.
+
+BEGIN;
+
+ALTER TABLE documents DROP COLUMN IF EXISTS document_date_score;
+
+COMMIT;

internal/storage/migrations/026_accounting_api_keys.down.sql

@@ -0,0 +1,24 @@
+-- 026_accounting_api_keys.down.sql
+-- Rollback documentation for 026_accounting_api_keys.sql.
+-- Documentation only — archivdms has no migration runner; this file is the
+-- reviewed, copy-pasteable SQL an operator runs manually (psql) AFTER
+-- deploying a binary whose initSchema no longer creates the object, and
+-- inside an explicit transaction.
+--
+-- PRECONDITION: internal/storage/accounting_api_keys.go
+-- (Store.initAccountingAPIKeysSchema) must be removed from storage.New()
+-- first — otherwise the next process start recreates the table.
+--
+-- DATA LOSS: destroys all issued accounting API keys (hashes only, raw keys
+-- were never stored). Every buchhaltung integration using the Pull-API loses
+-- access and must be re-issued a new key. No GoBD document data is touched:
+-- accounting_api_keys holds credentials, not archived records. The audit
+-- entries referencing "key:<id>" survive in audit_log but their id becomes
+-- unresolvable — accept this only when the whole feature is being withdrawn.
+
+BEGIN;
+
+DROP INDEX IF EXISTS idx_accounting_api_keys_tenant;
+DROP TABLE IF EXISTS accounting_api_keys;
+
+COMMIT;

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
 

internal/storage/processing_jobs.go

@@ -340,6 +340,36 @@ func (s *Store) ReapStaleJobs(ctx context.Context, timeout time.Duration, maxRet
 	return len(stale), nil
 }
 
+// CountProcessingJobsByStatus liefert die Queue-Länge je Status über ALLE
+// Mandanten hinweg. Bewusst ohne tenant_id-Filter: einziger Aufrufer ist der
+// betriebsinterne Prometheus-Endpunkt GET /metrics (FDN-08), der nur
+// aggregierte Zahlen ohne Mandantenbezug ausgibt — es verlassen keine
+// mandantenbezogenen Daten das System. Für mandantenbezogene Auswertungen
+// niemals diese Funktion nutzen.
+func (s *Store) CountProcessingJobsByStatus(ctx context.Context) (map[string]int64, error) {
+	rows, err := s.db.Query(ctx, `
+		SELECT status, count(*) FROM processing_jobs GROUP BY status
+	`)
+	if err != nil {
+		return nil, fmt.Errorf("storage: count processing jobs by status: %w", err)
+	}
+	defer rows.Close()
+
+	out := map[string]int64{}
+	for rows.Next() {
+		var status string
+		var n int64
+		if err := rows.Scan(&status, &n); err != nil {
+			return nil, fmt.Errorf("storage: scan processing job count: %w", err)
+		}
+		out[status] = n
+	}
+	if err := rows.Err(); err != nil {
+		return nil, fmt.Errorf("storage: iterate processing job counts: %w", err)
+	}
+	return out, nil
+}
+
 // RequeueJob stellt einen Job (typischerweise einen dauerhaft 'failed'
 // gelaufenen) wieder in die Queue und setzt retry_count zurück. Wird vom
 // späteren manuellen Retry-Endpunkt (Phase 3) genutzt; tenant-scoped.