Gegenbuch: Dienstkonto statt Token, .env mit gueltigen Werten

Blocker behoben: Ich hatte ein dauerhaftes API-Token vorausgesetzt - das gibt
es in OpenCRM nicht. Zugangstoken leben 15 Minuten, der Gegenbuch-Container
waere nach dem ersten Durchlauf gestorben. Aufgefallen erst durch die Frage des
Betreibers, woher er den Token nimmt.

Loesung: Das Gegenbuch meldet sich bei jedem Lauf selbst an, mit einem eigenen
Benutzerkonto, dessen Rolle ausschliesslich audit:read traegt. Damit kann es
nur Pruefwerte lesen - keine Kundendaten, keine Aenderungen. CRM_TOKEN bleibt
fuer Tests moeglich, ist aber nicht mehr der Normalweg. Fehlerfaelle (falsches
Passwort, Anmelde-Bremse, CRM nicht erreichbar) werden unterschieden und im
Klartext gemeldet.

.env.example nennt jetzt zu jedem Schalter die gueltigen Werte - bisher liess
sich nur raten, ob es prod oder production heisst. Einschliesslich des Falls
"erst nur Staging testen, Prod spaeter dazunehmen".

Beide READMEs um "Zugang einrichten" ergaenzt: Rolle mit nur audit:read,
Benutzer damit, Zugangsdaten in die .env. Mit dem Hinweis, dass jede Anmeldung
im Audit-Log erscheint - gewollt, denn so faellt auch auf, wenn das Gegenbuch
aufhoert zu arbeiten.

Verifiziert gegen eine Attrappe, die wie das echte CRM eine Anmeldung verlangt.

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

docs/todo.md

@@ -97,6 +97,30 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
 
 ## ✅ Erledigt
 
+- [x] **🔑 Gegenbuch: Dienstkonto statt Token, .env mit gueltigen Werten** (2026-08-22)
+  - **Blocker gefunden und behoben:** Ich hatte ein dauerhaftes API-Token
+    vorausgesetzt – das gibt es in OpenCRM gar nicht. Zugangstoken leben
+    **15 Minuten**; der Gegenbuch-Container waere nach dem ersten Durchlauf
+    gestorben. Aufgefallen erst, als der Betreiber fragte, woher er den Token
+    nimmt.
+    Loesung: Das Gegenbuch meldet sich bei **jedem Lauf selbst an** – mit einem
+    eigenen Benutzerkonto, dessen Rolle ausschliesslich `audit:read` traegt.
+    Damit kann es nur Pruefwerte lesen: keine Kundendaten, keine Aenderungen.
+    `CRM_TOKEN` bleibt fuer Tests moeglich, ist aber nicht mehr der Normalweg.
+  - Fehlerfaelle sauber gemeldet: falsches Passwort → Klartext statt HTTP-Code,
+    Anmelde-Bremse (429) benannt, CRM nicht erreichbar unterschieden.
+  - **`.env.example` nennt jetzt die gueltigen Werte** – bisher liess sich nur
+    raten, ob es `prod` oder `production` heisst. Fuer jeden Schalter steht
+    dabei, was erlaubt ist, inkl. des Falls „erst nur Staging testen, Prod
+    spaeter dazunehmen“ (`COMPOSE_PROFILES=staging` → `prod,staging`).
+  - Beide READMEs um „Zugang einrichten“ ergaenzt: Rolle mit nur `audit:read`,
+    Benutzer damit, Zugangsdaten in die `.env`. Mit dem Hinweis, dass jede
+    Anmeldung im Audit-Log erscheint – gewollt, denn so sieht man auch, wenn
+    das Gegenbuch aufhoert zu arbeiten.
+  - Verifiziert gegen eine Attrappe, die wie das echte CRM eine Anmeldung
+    verlangt: Anmeldung + Lauf erfolgreich, falsches Passwort → verstaendliche
+    Meldung, exit 1.
+
 - [x] **🐳 Gegenbuch als Docker-Setup, lokales Buch auf eigener Maschine** (2026-08-22)
   - Betreiber-Entscheidung: Das Gegenbuch laeuft auf einer **eigenen Maschine**
     fuer Prod und Staging; ein externes Git-Repository entfaellt, das Buch