Gegenbuch als Docker-Setup, lokales Buch auf eigener Maschine

Betreiber-Entscheidung: Das Gegenbuch laeuft auf einer eigenen Maschine fuer
Prod und Staging; ein externes Git-Repository entfaellt, das Buch liegt lokal.
Die Trennung, auf die es ankommt, ist damit gegeben - wer OpenCRM uebernimmt,
kommt nicht ans Buch.

Richtung bewusst so herum: Das Gegenbuch holt ueber HTTPS mit einem Token, das
nur audit:read kann. OpenCRM kennt weder Adresse noch Schluessel des
Gegenbuchs. Kein SSH-Zugang zum CRM noetig.

tools/audit-notary/ enthaelt jetzt Dockerfile, entrypoint.sh,
docker-compose.yml und .env.example. Zwei Dienste (prod, staging) mit
getrennten Verzeichnissen und Schluesseln, gesteuert ueber COMPOSE_PROFILES -
dasselbe Muster wie beim Caddy-Profil im Hauptstack. Der Signaturschluessel
wird beim ersten Start auf der Gegenbuch-Maschine erzeugt.

Lokaler Betrieb ist jetzt ein vollwertiger Modus statt eines Testschalters. Die
Erfolgsmeldung benennt bei jedem Lauf, was abgedeckt ist und was nicht - statt
der frueheren pauschalen Formulierung "kein Manipulationsschutz", die im
Einsatz auf eigener Maschine schlicht falsch war.

Verifiziert mit echtem Docker-Build gegen eine CRM-Attrappe: Genesis ohne
Bestaetigung -> Code 4; mit Bestaetigung Normalbetrieb exit 0; Eintrag
veraendert -> Alarm exit 2; Eintraege geloescht -> Alarm exit 2; Siegel
verschwunden -> Alarm.

Behoben beim Bauen: useradd -u 1000 || true verschluckte, dass UID 1000 im
Node-Image vergeben ist - der Container startete gar nicht.

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

tools/audit-notary/.env.example

@@ -0,0 +1,47 @@
+# ============================================================
+#  Gegenbuch für OpenCRM
+# ============================================================
+# Diese Datei gehört auf den Gegenbuch-Rechner – NICHT auf den CRM-Server.
+#
+# Was hier passiert: Der Rechner holt regelmäßig einen kurzen Kontrollwert von
+# OpenCRM ab und schreibt ihn in ein Buch, das nur hier liegt. Wird später im
+# CRM etwas nachträglich verändert, widerspricht das dem Buch.
+#
+# Welche Bücher sollen laufen?
+COMPOSE_PROFILES=prod,staging
+
+# Nur Kosmetik – steht in den Einträgen des Buchs.
+NOTAR_EMAIL=gegenbuch@example.de
+
+# ---------------- Produktion ----------------
+# Von welcher OpenCRM-Instanz wird geholt?
+PROD_CRM_URL=https://crm.example.de
+
+# Token eines Benutzers mit dem Recht audit:read – MEHR NICHT.
+# Damit lassen sich ausschließlich Prüfwerte lesen: keine Kundendaten, keine
+# Änderungen. Selbst wenn es abhandenkommt, ist damit nichts anzufangen.
+PROD_CRM_TOKEN=
+
+# Wie oft geprüft wird (Sekunden). 3600 = stündlich.
+# Kürzer heißt: kleineres Zeitfenster, in dem eine Änderung unbemerkt bliebe.
+PROD_INTERVAL=3600
+
+# Beim ALLERERSTEN Start einmalig auf true setzen, danach wieder leeren.
+# Grund: Die erste Eintragung legt fest, was als Ausgangszustand gilt – das
+# soll nicht versehentlich passieren.
+PROD_GENESIS_ACK=
+
+# Normalerweise leer lassen. Nur nötig, wenn das Gedächtnis des Gegenbuchs
+# verlorenging (z. B. Verzeichnis gelöscht) und du geklärt hast, warum.
+PROD_ADOPT_ACK=
+
+# Wo das Buch liegt. DIESES VERZEICHNIS GEHÖRT INS BACKUP.
+PROD_DIR=./data/prod
+
+# ---------------- Test / Staging ----------------
+STAGING_CRM_URL=https://staging.example.de
+STAGING_CRM_TOKEN=
+STAGING_INTERVAL=3600
+STAGING_GENESIS_ACK=
+STAGING_ADOPT_ACK=
+STAGING_DIR=./data/staging