feat: Row-Level-Security für Mandantenisolation auf DB-Ebene

Postgres-RLS-Policies auf allen Tabellen mit echten Mandanten-
Geschäftsdaten (antrag und alles darüber verkettete, abteilung,
werkzeug/werkzeug_sperre, genehmiger_rolle/freigabe_regel,
loeschfrist_einstellung). Kritischer Fund vor der Umsetzung: die
Anwendung verbindet als postgres-Superuser, der RLS immer umgeht -
Migration 0021 legt deshalb zusätzlich eine eingeschränkte Rolle
"deklarix_app" an, nur für die greifen die Policies tatsächlich.

internal/store/tenant_scope.go: WithTenantScope öffnet eine Transaktion
und setzt Sitzungsvariablen (app.account_id/app.is_betreiber) per
set_config mit Parameterbindung; alle Store-Methoden laufen jetzt über
s.db(ctx) statt direkt s.Pool. Jede require*-Middleware umschließt die
komplette Handler-Ausführung damit - jeder Request läuft dadurch auch
atomar in einer Transaktion (positiver Nebeneffekt).

Live end-to-end verifiziert (echter HTTP-Server + DATABASE_URL_APP auf
die eingeschränkte Rolle gesetzt): zwei Firmen registriert, Isolation
über Abteilung/Antrag/Bewertung bestätigt, zentraler NULL-Katalog für
beide sichtbar. Produktivbetrieb braucht noch einen manuellen Schritt
(Passwort für deklarix_app setzen + DATABASE_URL_APP konfigurieren,
siehe CLAUDE.md) - die Migration allein aktiviert noch nichts, solange
die App weiter als Superuser verbindet.

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

CLAUDE.md

@@ -633,6 +633,99 @@ und live per curl gegen echten Server + Postgres verifiziert.
 
 ---
 
+## Row-Level-Security (2026-09-01, Migration 0021)
+
+**Kritischer Fund vor der Umsetzung:** Sowohl lokal als auch auf dem
+Produktivserver verbindet sich die Anwendung als `postgres`-Rolle — ein
+echter Postgres-**Superuser**. Superuser umgehen RLS-Policies *immer*,
+unabhängig von `FORCE ROW LEVEL SECURITY` (das wirkt nur beim
+Tabellenbesitzer, nicht bei Superusern — eine harte, nicht
+überschreibbare Postgres-Regel). Policies allein hätten also nichts
+bewirkt. Migration 0021 legt deshalb zusätzlich eine neue,
+eingeschränkte Rolle **`deklarix_app`** an (kein Superuser, kein
+Tabellenbesitzer, `NOBYPASSRLS`, zunächst `NOLOGIN`) — nur für diese
+Rolle greifen die Policies tatsächlich.
+
+**Architektur:** `internal/store/tenant_scope.go` — `Store.db(ctx)`
+liefert entweder die aktive Transaktion (falls `WithTenantScope` sie
+gesetzt hat) oder den Pool direkt; alle ~69 vorherigen `s.Pool.Query/
+QueryRow/Exec`-Aufrufe wurden mechanisch auf `s.db(ctx).…` umgestellt.
+`WithTenantScope(ctx, accountID, isBetreiber, fn)` öffnet eine
+Transaktion, setzt zwei Sitzungsvariablen per `set_config(..., true)`
+(Parameterbindung, kein String-Interpolation — SQL-Injection-frei,
+automatisch auf die Transaktion begrenzt) — `app.account_id` und
+`app.is_betreiber` — und committet am Ende. `SetTenantScope` erlaubt,
+die Variable **mitten in einer laufenden** Transaktion nachzutragen
+(nötig bei `handleRegister`: die `account_id` ist erst nach
+`CreateAccount` bekannt). Jede der fünf `require*`-Middlewares
+(`requirePage/-API/-Admin/-Fachebene/-Betreiber`) umschließt die
+komplette Handler-Ausführung jetzt mit `withTenantScope` — jeder
+Request läuft dadurch automatisch in genau einer Transaktion, nicht nur
+die Store-Aufrufe, die ein Handler zufällig selbst noch mal prüft.
+**Nebeneffekt (bewusst, positiv):** ein Handler mit mehreren
+Schreibzugriffen ist jetzt atomar — schlägt ein späterer Schritt fehl,
+werden frühere Schritte desselben Requests zurückgerollt (vorher: keine
+Transaktion, ein halb fehlgeschlagener Handler konnte einen verwaisten
+Account ohne Nutzer hinterlassen).
+
+**Geschützte Tabellen** (`ENABLE ROW LEVEL SECURITY` + Policy
+`tenant_isolation`): `antrag`, `registereintrag`, `abteilung`,
+`werkzeug_sperre`, `genehmiger_rolle`, `freigabe_regel`,
+`loeschfrist_einstellung` (direkte `account_id`-Prüfung), `werkzeug`
+(nullable — `NULL` = zentraler Katalog, für alle lesbar, nur Betreiber
+darf `NULL`-Zeilen schreiben), `bewertung`/`entscheidung`/
+`freigabeschritt` (kein eigenes `account_id`, Policy prüft
+`antrag_id IN (SELECT id FROM antrag)` — erbt automatisch dieselbe
+Grenze wie `antrag`, da diese Unterabfrage in derselben Sitzung
+läuft), `nutzer_genehmiger_rolle` (analog über `genehmiger_rolle_id`).
+
+**Bewusst OHNE RLS** (dokumentiert in der Migration, kein Versehen):
+`account` (keine `account_id`-Spalte, muss bei Registrierung
+uneingeschränkt INSERT erlauben, bevor die ID bekannt ist), `app_user`
+(Login/Passwort-Reset suchen per E-Mail über alle Mandanten hinweg —
+die Ziel-`account_id` ist zu dem Zeitpunkt noch nicht bekannt),
+`session`/`password_reset_token` (werden nur über einen
+kryptographisch zufälligen, praktisch unerratbaren Token gesucht, kein
+sequentiell erratbarer Schlüssel), `audit_log` (plattformweites
+Protokoll ohne eigene `account_id`, wird ausschließlich vom Betreiber
+gelesen, der ohnehin alle Mandanten sieht).
+
+**Live end-to-end verifiziert** (nicht nur Unit-Tests): Rohes SQL
+gegen `deklarix_app` direkt per `psql` (Isolation, Betreiber-Bypass,
+Fail-Closed ohne Kontext, INSERT-Schutz gegen fremde `account_id` —
+alle vier Fälle bestätigt), danach derselbe Beweis noch mal über den
+echten laufenden HTTP-Server mit `DATABASE_URL_APP` auf `deklarix_app`
+gesetzt: zwei Firmen registriert, Abteilung/Antrag/Bewertung einer
+Firma über die andere nicht erreichbar, zentraler Werkzeugkatalog
+(NULL-`account_id`) für beide sichtbar. Dabei einen echten Bug gefunden
+und behoben: `handleRegister`s `startSession`-Aufruf nutzte noch
+`r.Context()` statt der lokalen, transaktionsbehafteten `ctx`-Variable
+— die Session-INSERT lief dadurch auf einer anderen (Pool-)Verbindung
+als der gerade erst angelegte, noch nicht committete Nutzer, was einen
+Fremdschlüssel-Konflikt auslöste und die gesamte Registrierung
+zurückrollte. Zwei dedizierte Tests
+(`internal/store/tenant_scope_test.go`, `TestRLSAbteilungIsoliertZwischenMandanten`,
+`TestRLSVerhindertInsertFuerFremdenAccount`) laufen gegen die echte
+eingeschränkte Rolle und überspringen sich selbst sauber, wenn
+`DATABASE_URL_APP` nicht gesetzt ist (analog zum bestehenden
+`DATABASE_URL`-Skip-Muster).
+
+**Produktivbetrieb — noch ausstehender manueller Schritt.** Die
+Migration allein bewirkt in Produktion noch NICHTS (die App verbindet
+weiterhin als `postgres`-Superuser, `DATABASE_URL_APP` ist nicht
+gesetzt). Um RLS tatsächlich scharf zu schalten:
+1. `ALTER ROLE deklarix_app WITH LOGIN PASSWORD '<neu generiertes Secret>';`
+   einmalig auf dem Zielserver ausführen (das Passwort steht nicht im
+   Code/in Migrationen — Secrets gehören nicht in ein versioniertes
+   Repo).
+2. `DATABASE_URL_APP=postgres://deklarix_app:<secret>@<host>/deklarix?...`
+   in `/etc/deklarix/deklarix.env` eintragen.
+3. Dienst neu starten.
+`DATABASE_URL` (Migrationen, DDL-Rechte) bleibt unverändert auf der
+bisherigen, privilegierten Verbindung.
+
+---
+
 ## Löschfristen je Datenklasse (2026-09-01, Migration 0020)
 
 Schließt `rules/OPEN.md`, Punkt 4. Recherche ergab: die DSGVO nennt
@@ -1289,13 +1382,10 @@ journalctl -u deklarix -f
 - ~~Löschfristen je Datenklasse~~ — **erledigt 2026-09-01**, siehe
   „Löschfristen je Datenklasse" weiter oben: pro Mandant einstellbar
   statt hartkodiert, da die DSGVO selbst keine festen Fristen nennt.
-- **Mandantenisolation auf Datenbankebene (Postgres Row-Level Security)**
-  — die Frontend-Spezifikation fordert das explizit ("nicht in der
-  Anwendungslogik"), aktuell ist Isolation ausschließlich
-  anwendungsseitig (Handler-Vergleich `AccountID`). Umstellung auf RLS
-  ist ein bewusst noch nicht getroffener Architektur-Entscheid —
-  Aufwand und Zeitpunkt mit dem Nutzer klären, bevor mehr Tabellen
-  entstehen, die sonst nachträglich migriert werden müssten.
+- ~~Mandantenisolation auf Datenbankebene (Postgres Row-Level Security)~~
+  — **Code/Migration/Tests erledigt 2026-09-01, Produktivbetrieb noch
+  ausstehend** (siehe „Row-Level-Security" weiter oben für den vollen
+  Stand und was auf dem Produktivserver noch manuell nachzuziehen ist).
 - ~~"Admin und KI-Verantwortlicher" beim Firma-Onboarding~~ — **pragmatisch
   gelöst, kein Datenmodell-Umbau:** `app_user.role` bleibt ein einzelner
   Wert (kein `roles`-Array, keine zwei `app_user`-Zeilen pro Person).