refactor: E-Mail-Vorlagen als Liste + eigene Bearbeiten-Seite statt Formular-Stapel

Auf Nutzerfeedback: die erste Version zeigte alle bekannten Vorlagen als
gestapelte Formulare auf einer Seite. Jetzt wie Werkzeugkatalog/
Nutzerverwaltung: eine Liste (GET .../email-vorlagen) mit Klick auf eine
eigene Bearbeiten-Seite je Typ (GET/POST .../email-vorlagen/{typ}) -
skaliert sauber, wenn mit der Zeit weitere Benachrichtigungstypen
dazukommen, statt eine immer länger werdende Formular-Stapel-Seite.

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

CLAUDE.md

@@ -640,9 +640,15 @@ sein — für E-Mails, die an die eigenen Mitarbeiter einer Firma gehen,
 durch den Mandanten selbst; für E-Mails, die die Plattform an
 Mandanten-Admins schickt, durch den Betreiber. Zweistufig wie der
 Werkzeugkatalog: `email_vorlage.account_id` NULL = plattformweiter
-Standard (`GET/POST /betreiber/email-vorlagen`, nur Betreiber), gesetzt
-= mandantenspezifische Übersteuerung (`GET/POST /verwaltung/email-
-vorlagen`, nur Admin). `ResolveEmailVorlage` liefert die eigene
+Standard (`/betreiber/email-vorlagen`, nur Betreiber), gesetzt =
+mandantenspezifische Übersteuerung (`/verwaltung/email-vorlagen`, nur
+Admin) — jeweils ein eigener Nav-Punkt (nicht als weiterer Button auf
+einer bestehenden Seite), mit Liste + eigener Bearbeiten-Seite je Typ
+(`GET .../email-vorlagen` Liste, `GET/POST .../email-vorlagen/{typ}`
+Bearbeiten) statt eines einzigen, mit allen Formularen gestapelten
+Screens — auf ausdrücklichen Nutzerwunsch, da mit der Zeit weitere
+Benachrichtigungstypen dazukommen sollen und eine gestapelte Liste dann
+unübersichtlich würde. `ResolveEmailVorlage` liefert die eigene
 Übersteuerung, falls vorhanden, sonst den Plattform-Standard — ein
 Mandant, der nie etwas anpasst, bekommt automatisch jede künftige
 Änderung des Plattform-Standards. `emailVorlageTypen` in