Aufsicht und Eingriff getrennt: neuer Haken "Audit-Betrieb"

Die DSGVO-Rolle trug audit:* komplett, also auch audit:admin. Ein
DSGVO-Beauftragter konnte damit seal-backlog, rehash und cleanup - seine
eigene Beweisgrundlage ersetzen. Wer das Protokoll beaufsichtigt, darf es
nicht umschreiben koennen. Dieselbe Klasse wie R184-02: falsche Domaene,
zu breit gebuendelt.

Der naheliegende Fix waere falsch gewesen. audit:admin einfach aus der
DSGVO-Rolle zu streichen haette es heimatlos gemacht: Die Admin-Rolle ist
ausdruecklich ohne audit/gdpr gebaut, einzige verbleibende Quelle waere
der Entwicklerzugriff - der alles gibt. Prod versiegeln haette dann
Vollzugriff vorausgesetzt.

Deshalb eine eigene versteckte Rolle "Audit-Betrieb" (audit:read +
audit:admin), zugewiesen ueber eine Checkbox wie DSGVO/Entwickler. DSGVO
behaelt audit:read + audit:export + gdpr:*. Fuer kein bestehendes Konto
weitet sich etwas aus; es wird enger, und wer eingreifen koennen soll,
bekommt es ausdruecklich.

Keine zusaetzliche Rechte-Huerde davor, weil das am Henne-Ei-Problem
scheitert: Nach der Aufteilung haelt zunaechst niemand audit:admin,
koennte ihn also auch niemand vergeben. Stattdessen wird die Vergabe
laut - CRITICAL im Protokoll und PERMISSION_CHANGED/CRITICAL im
Alarmkanal, samt Kennzeichen, ob sich jemand den Haken selbst gesetzt hat.

Nebenbei geschlossen: setUserGdprAccess() legte die DSGVO-Rolle im
Notfallpfad mit audit:* komplett an - eine zweite Liste, die dasselbe
bedeuten sollte und die Buendelung stillschweigend zurueckgebracht haette.

ACHTUNG beim Deploy: Bestehende DSGVO-Konten verlieren audit:admin. Wer
Prod versiegeln will, muss sich vorher "Audit-Betrieb" ankreuzen.

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

tools/audit-notary/README.md

@@ -195,12 +195,12 @@ Im CRM, als Administrator:
 4. E-Mail und Passwort in die `.env` des Gegenbuchs eintragen
    (`PROD_CRM_EMAIL` / `PROD_CRM_PASSWORD`).
 
-> **Nicht den DSGVO-Haken benutzen.** Der sieht naheliegend aus („Audit-Logs,
-> Datenschutz"), vergibt aber `audit:` **komplett** – einschließlich
-> `audit:admin` mit `seal-backlog`, `rehash` und `cleanup`. Ein Einbruch auf
-> dieser Maschine hätte damit nicht nur den Wächter, sondern gleich die Mittel,
-> das Bewachte umzuschreiben. Das Passwort steht hier im Klartext in der
-> `.env`; es muss so wenig wert sein wie möglich.
+> **Weder den DSGVO- noch den Audit-Betrieb-Haken setzen.** Der DSGVO-Haken
+> gibt zusätzlich Leserechte auf personenbezogene Daten und den Export; der
+> Haken „Audit-Betrieb" gibt `audit:admin` mit `seal-backlog`, `rehash` und
+> `cleanup`. Ein Einbruch auf dieser Maschine hätte damit nicht nur den
+> Wächter, sondern gleich die Mittel, das Bewachte umzuschreiben. Das Passwort
+> steht hier im Klartext in der `.env`; es muss so wenig wert sein wie möglich.
 
 Mit `audit:read` allein kann dieses Konto **nur Prüfwerte lesen** – keine
 Kundendaten, keine Verträge, nichts ändern und nichts versiegeln. Selbst wenn