Backend-Arbeitsstand: ERP-Sync, Lieferlebenszyklus, Reports + config.toml

Bringt das Backend vom initialen Skeleton auf den aktuellen Arbeitsstand
(Clean Architecture: domain → application → infrastructure → api).

Wesentliche Bereiche:
- ERP-Anbindung (MSSQL-Pull der Touren, Import-Scheduler, Rückschreiben)
- Lieferlebenszyklus: Scan/Hold/Cancel/Complete, Gutschriften, Notizen,
  Bild-Anhänge, Unterschriften, PDF-Lieferreport → DOCUframe
- Stammdaten: Kunden, Artikel, Lager, Zahlungsarten, Services
- Keycloak-JWT-Gate + Fahrer-Provisionierung via Admin-API
- Admin-API-Key-Gate (X-Admin-Api-Key) für Maschinen-Endpunkte

Jüngste Änderungen dieser Session:
- Belegspezifische Kontaktdaten: alle ERP-Adressen (Beleg-/Liefer-/
  Rechnungsadresse, Ansprechpartner, Kundenstamm) mit Telefon/Mobil/
  E-Mail werden gesynct (Migration 0029, MSSQL-Query, TourDetails)
- Konfiguration von .env (envy/dotenvy) auf config.toml (toml/serde)
  umgestellt; Vorlage config.example.toml, Pfad via HOLZLEITNER_CONFIG

Nicht im Repo (per .gitignore): config.toml (Secrets), data/ (Laufzeit-/
Kundendaten), demo.mp4, .claude/, variocontrol-ai/.

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

migrations/0026_delivery_report_jobs.sql

@@ -0,0 +1,40 @@
+-- 0026_delivery_report_jobs.sql
+--
+-- Zustandsanker für die Übertragung des PDF-Lieferreports an DOCUframe.
+-- Beim Abschluss wird der Report erzeugt und in DOCUframe abgelegt; das ist
+-- ein mehrstufiger, netzabhängiger Vorgang (Upload → ~ObjectID → Makro
+-- `_SV_assignDeliveryReport`). Damit nichts verloren geht und fehlgeschlagene
+-- Übertragungen per Cron wiederholt werden können, hält diese Tabelle den
+-- Fortschritt **hart** in Postgres.
+--
+-- Genau eine Zeile pro Lieferung (PK = delivery_id). `status` ist die
+-- Resume-Marke; ein Retry führt nur die noch offenen Schritte aus:
+--   * 'pending'  — angelegt, noch nichts übertragen
+--   * 'uploaded' — PDF liegt in DOCUframe, `docuframe_object_id` gesetzt,
+--                  Makro-Zuordnung steht noch aus
+--   * 'done'     — Makro erfolgreich; lokale Dateien wurden aufgeräumt
+--
+-- Fehlersemantik: schlägt ein Schritt fehl, bleibt `status` auf der erreichten
+-- Stufe, `last_error`/`attempts`/`last_attempt_at` werden gesetzt. Der Cron
+-- greift alle Zeilen mit status <> 'done' erneut auf.
+
+CREATE TABLE delivery_report_jobs (
+    delivery_id          UUID PRIMARY KEY REFERENCES deliveries(id) ON DELETE CASCADE,
+    belegnummer          TEXT NOT NULL,
+    status               TEXT NOT NULL DEFAULT 'pending'
+                            CHECK (status IN ('pending', 'uploaded', 'done')),
+    -- DOCUframe ~ObjectID des hochgeladenen Reports — hart gespeichert nach
+    -- dem Upload, damit ein Retry nicht doppelt hochlädt.
+    docuframe_object_id  TEXT,
+    -- Zeitpunkt der erfolgreichen Makro-Zuordnung (= „Report hochgeladen").
+    report_uploaded_at   TIMESTAMPTZ,
+    attempts             INT NOT NULL DEFAULT 0,
+    last_error           TEXT,
+    last_attempt_at      TIMESTAMPTZ,
+    created_at           TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at           TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+
+-- Schneller Zugriff des Retry-Cron auf offene Jobs.
+CREATE INDEX delivery_report_jobs_open ON delivery_report_jobs (status)
+    WHERE status <> 'done';