feat: Zweck-Vokabular auf 12 Kategorien erweitert, Werkzeug-Formular im Enterprise-Look überarbeitet

Sechs neue Zweck-Kategorien (Datenanalyse, Video, Audio/Sprache,
Kundenservice/Chatbot, Präsentation/Design, Automatisierung/Agenten)
ergänzen die ursprünglichen sechs — deckt jetzt die tatsächliche
Bandbreite an Einsatzgebieten ab statt nur klassischer Wissensarbeit.

Werkzeug-Formular (Betreiber + Mandant, gleiche Vorlage) neu strukturiert:
Karten-Layout mit thematischen Abschnitten, 2-Spalten-Grid für kurze
Felder, Chip-Gruppen statt langer Checkbox-Listen, abgesetzte
Gefahrenzone für den Löschen-Button. Dabei einen vorbestehenden Bug
gefunden und behoben: das Lösch-Formular war fest auf die
Betreiber-Route verdrahtet, obwohl dieselbe Vorlage auch vom
Mandanten-Formular genutzt wird.

CLAUDE.md

@@ -39,8 +39,8 @@ Regelbasiert, nicht ML: die Ableitungsregeln (Datenklasse, KI-VO-
 Einstufung, Anforderungsprofil) liegen als versionierte YAML-Dateien
 vor, nicht im Code — ein fachlich Verantwortlicher soll sie anpassen
 können, ohne Go-Code anzufassen. Ein LLM ist v1 höchstens optional zur
-Zweckerkennung aus dem Freitext vorgesehen (Textgenerierung/Übersetzung/
-Code/Bild/Transkription/Recherche erkennen), nie für die Einstufung
+Zweckerkennung aus dem Freitext vorgesehen (die zwölf Zweck-Kategorien
+erkennen, siehe `gueltigeZwecke` weiter unten), nie für die Einstufung
 selbst — und auch dort nur als Vorschlag, den der Mensch bestätigt.
 
 ---
@@ -269,13 +269,23 @@ aussahen — `formatAufbewahrung()` zeigt entsprechend "unbekannt" statt
 "0 Tage".
 
 `geeignete_zwecke` ist seit derselben Migration ein kontrolliertes
-Vokabular statt Freitext: das Formular zeigt Checkboxen für genau die
-sechs Zweck-Kategorien aus dem Fragebogen (Textgenerierung,
-Übersetzung, Code, Bild, Transkription, Recherche — `gueltigeZwecke` in
-`betreiber_werkzeug_handlers.go`), serverseitig validiert
-(`istGueltigerZweck`). Grund: ein künftiger automatischer Zweckabgleich
-(Bewertungslogik Schritt 3, weiterhin nicht gebaut) würde an
-inkonsistentem Freitext ("Text" statt "Textgenerierung") scheitern.
+Vokabular statt Freitext: das Formular zeigt Checkboxen statt eines
+Freitextfelds (`gueltigeZwecke` in `betreiber_werkzeug_handlers.go`,
+serverseitig validiert via `istGueltigerZweck`). Grund: ein künftiger
+automatischer Zweckabgleich (Bewertungslogik Schritt 3, weiterhin nicht
+gebaut) würde an inkonsistentem Freitext ("Text" statt
+"Textgenerierung") scheitern. Am 2026-08-31 von sechs auf zwölf
+Kategorien erweitert, nachdem der Nutzer zurecht einwandte, dass sechs
+Kategorien die tatsächliche Bandbreite an Einsatzgebieten nicht
+abdecken: Textgenerierung, Übersetzung, Code, Bild, Transkription,
+Recherche, **Datenanalyse, Video, Audio/Sprache,
+Kundenservice/Chatbot, Präsentation/Design, Automatisierung/Agenten**.
+Es gibt keinen einheitlichen Branchenstandard für KI-Funktions-
+kategorien (regulatorische Taxonomien wie die KI-VO selbst oder OECD/
+NIST klassifizieren nach Risiko, nicht nach Funktion; Marktplatz-
+Kategorien wie bei G2 sind Marketing, kein Standard) — diese zwölf
+sind Deklarix' eigene, bewusst begrenzte Liste für den künftigen
+Zweckabgleich, keine allgemeine KI-Taxonomie.
 
 Neues Feld `subprozessoren` (TEXT[], Migration 0015) macht
 Unterauftragsverarbeiter (z. B. Anthropic bei Microsoft 365 Copilot,
@@ -319,8 +329,8 @@ bleibt, mit welchem Katalogstand ein Vorschlag erzeugt wurde.
    nicht erfüllen — Grund je Werkzeug festhalten, auch aussortierte
    Werkzeuge werden im Ergebnis mit Begründung gezeigt.
 3. **Zweckabgleich.** Aus `beschreibung`/`ergebnis` den Zweck ableiten
-   (Textgenerierung, Übersetzung, Code, Bild, Transkription, Recherche)
-   und gegen `geeignete_zwecke` filtern.
+   (die zwölf Kategorien aus `gueltigeZwecke`, siehe Werkzeugkatalog
+   weiter unten) und gegen `geeignete_zwecke` filtern.
 4. **Rangfolge.** Verbleibende Werkzeuge sortieren: EU-Verarbeitung,
    Training standardmäßig aus, kurze Aufbewahrung, Aktualität der
    Prüfung.
@@ -467,7 +477,41 @@ kein separates Desktop-Template.
 **Tabellen** (`table`/`th`/`td` in `app.css`) sind seit dieser Änderung
 gestylt (vorher komplett ungestylt, betraf v. a. `register_liste.html`);
 breite Tabellen stehen in einem `.table-scroll`-Wrapper (horizontales
-Scrollen auf dem Handy statt gequetschter Spalten).
+Scrollen auf dem Handy statt gequetschter Spalten). Seit 2026-08-31 hat
+`.table-scroll` zusätzlich einen rechten Fade-Rand (`mask-image`) —
+ohne den sah eine am Fensterrand abgeschnittene breite Tabelle wie ein
+Rendering-Fehler aus statt wie "hier geht's mit Scrollen weiter" (per
+Screenshot am Werkzeugkatalog beobachtet: die letzten zwei Spalten
+waren nur als einzelne Buchstaben sichtbar, ganz ohne Hinweis auf mehr
+Inhalt).
+
+**Formulare** (`.form-card`/`.form-section`/`.form-grid`/`.chip-group`
+in `app.css`, seit 2026-08-31, erstmals angewendet auf
+`betreiber_werkzeug_form.html`): vorher war jedes Formular eine flache
+Spalte aus `<label>`+`<input>` ohne Gruppierung — bei einem Formular
+mit über einem Dutzend Feldern (Werkzeug anlegen) wirkte das "klobig,
+einfach nur untereinander" (O-Ton Nutzer). Jetzt: `.form-card` (weiße
+Karte mit Rahmen/Schatten, Ant-Design-Tokens aus `design/enterprise.css`
+übernommen) enthält mehrere `<fieldset class="form-section">`
+(thematische Abschnitte mit Titel, per `border-top` getrennt), darin
+`.form-grid` (2 Spalten ab 640px für kurze Felder wie Name/Anbieter
+nebeneinander, `.form-full` erzwingt volle Breite für lange Felder).
+Checkbox-/Radio-Gruppen mit vielen Optionen (Verarbeitungsort, die
+zwölf Zwecke) sind `.chip-group` — abgerundete Pillen statt einer
+langen Untereinander-Liste, ausgewählte Chips werden über
+`:has(input:checked)` blau hervorgehoben (kein JavaScript). Ein
+Löschen-Button steht nicht mehr einfach unter dem Formular, sondern in
+einer abgesetzten `.form-gefahrenzone`-Fußzeile der Karte. Dieselben
+Klassen sind bewusst generisch (nicht an ein Formular gebunden) — noch
+nicht auf andere Formulare (Login/Registrierung, Fragebogen, übrige
+Admin-Formulare) angewendet, das wäre der nächste Schritt, falls
+gewünscht. Beim Umbau auffällig gewordener, vorbestehender Bug: das
+Lösch-Formular in `betreiber_werkzeug_form.html` war fest auf
+`/betreiber/werkzeuge/{id}/loeschen` verdrahtet, obwohl dieselbe
+Vorlage auch vom Mandanten-Formular (`/verwaltung/werkzeuge/...`)
+genutzt wird — ein Mandant hätte beim Löschen eines eigenen Werkzeugs
+403 bekommen. Jetzt `{{.ActionBase}}/{{.ID}}/loeschen`, wie die
+Formular-`action` selbst.
 
 **Verifikationsmethode für CSS-Änderungen:** Live-Cookie-Auth per
 Chromium-Headless/CDP ist im Sandbox-Environment nicht möglich (kein