Spec erweitert: aus welchem Postfach eine Mail geht, je Mailart

Der Betreiber will die Meldungen dieses Systems aus einem eigenen Postfach
schicken, ohne dass jede andere Mail mitwandert. Heute kennt die Zuordnung nur
fuenf Zwecke — alles mit demselben Zweck geht aus demselben Postfach.

Dazu kommt eine Ebene UEBER den Zwecken, kein Ersatz: je Mailart ein Postfach,
Vorgabe 'wie der Zweck'. Ohne Eintrag aendert sich nichts. Der Katalog der 16
Mailarten existiert schon fuer die Vorschau und wird dabei zur EINEN Liste,
damit es keine zweite gibt, die man vergessen kann.

Ausdruecklich NICHT darin: Postfaecher anlegen und loeschen. Das ist ein eigenes
Projekt — ein Postfach zu loeschen, auf das noch drei Mailarten zeigen, darf
nicht still geschehen. Die fuenf vorhandenen genuegen fuer dieses System.

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

docs/superpowers/specs/2026-08-03-fruehwarnsystem-design.md

@@ -161,10 +161,14 @@ Cursor: `instances.security_log_offset` (bigint), `hosts.security_log_seen_at`.
 
 ### Benachrichtigung
 
-`SecurityBlockMail`, aus dem **System**-Postfach — nach dem Muster von
-`NewDeviceSignInMail`. Nicht aus Support: das ist kein Gespräch, und eine
-Antwort darauf soll kein Ticket öffnen. (Nebenbei umgeht das auch das bekannte
-Problem des Support-Postfachs, dem der SMTP-Benutzername fehlt.)
+`SecurityBlockMail`, als **eigene Mailart** im Katalog, mit dem Zweck
+**System** als Vorgabe — nach dem Muster von `NewDeviceSignInMail`. Nicht
+Support: das ist kein Gespräch, und eine Antwort darauf soll kein Ticket öffnen.
+(Nebenbei umgeht das auch das bekannte Problem des Support-Postfachs, dem der
+SMTP-Benutzername fehlt.)
+
+Über die Wegwahl aus Abschnitt 3a kann der Betreiber sie jederzeit auf ein
+anderes Postfach legen, ohne dass eine andere Mail mitwandert.
 
 - **Instanz gesperrt** → an die Kontoadresse des Inhabers, mit Link auf die
   Sperrliste im Portal.
@@ -192,6 +196,65 @@ anderen Kunden, nie die des Hosts.
 - Auf der **Host-Detailseite** dasselbe für Host-Sperren.
 - Auf der **Übersicht** ein Hinweis, solange irgendwo eine Sperre aktiv ist.
 
+---
+
+## 3a. Aus welchem Postfach eine Mail geht — je Mailart einstellbar
+
+**Warum das hier steht:** der Betreiber will die Meldungen dieses Systems aus
+einem eigenen Postfach schicken (etwa `info@` oder später ein `alert@`), ohne
+dass dafür jede andere Mail mitwandert. Heute geht das nicht: die Zuordnung
+kennt nur **fünf Zwecke**, und alles, was denselben Zweck hat, geht aus
+demselben Postfach.
+
+### Was es schon gibt
+
+- `Mailbox` — Postfächer mit Adresse, Anzeigename, Zugangsdaten. Fünf sind
+  vorhanden: `no-reply`, `support`, `billing`, `office`, `info`.
+- `MailPurpose` — fünf Zwecke, je einem Postfach zugeordnet (`Settings`).
+- `MailPreviews::all()` — der Katalog **aller 16 Mailarten** mit lesbaren Namen,
+  bisher nur für die Vorschau benutzt.
+
+### Was dazukommt
+
+Eine Ebene **über** den Zwecken, kein Ersatz für sie:
+
+```
+Settings: mail.route.<mailart>  →  Postfach-Schlüssel   (leer = wie der Zweck)
+```
+
+`SendsFromMailbox::mailboxEnvelope()` fragt zuerst die Wegwahl der Mailart und
+fällt auf den Zweck zurück, wenn keine gesetzt ist. **Bestehendes Verhalten
+ändert sich damit nicht** — ohne Eintrag geht alles genau wie heute.
+
+Damit eine Mailart ihren eigenen Weg kennen kann, braucht sie einen Schlüssel.
+Der Katalog in `MailPreviews` wird dafür zur **einen Liste**: er wandert in ein
+Register (`MailCatalogue`), das Schlüssel, lesbaren Namen und Vorgabe-Zweck je
+Mailart führt. Die Vorschau liest daraus, die Wegwahl liest daraus, und es gibt
+keine zweite Liste, die man vergessen kann.
+
+### Oberfläche
+
+Auf der bestehenden Seite **Mail** in der Konsole eine Tabelle: eine Zeile je
+Mailart, links der lesbare Name, rechts ein Auswahlfeld mit allen aktiven
+Postfächern und der Vorgabe „wie der Zweck (Support)". Gespeichert wie die
+Zwecke darüber.
+
+### Was hier NICHT gebaut wird
+
+**Postfächer anlegen, ändern und löschen.** Die Seite kann heute nur zuordnen
+und testen; ein neues `alert@` lässt sich dort nicht erzeugen. Das ist ein
+eigenes Projekt mit eigenen Fallstricken — ein Postfach zu löschen, auf das noch
+drei Mailarten zeigen, darf nicht still geschehen. Bis dahin stehen die fünf
+vorhandenen Postfächer zur Wahl, und das genügt für dieses System.
+
+### Prüfungen
+
+- Ohne Eintrag geht jede Mail aus demselben Postfach wie vorher.
+- Mit Eintrag geht genau diese eine Mailart woanders hin, alle anderen nicht.
+- Ein Eintrag, der auf ein gelöschtes oder abgeschaltetes Postfach zeigt, fällt
+  auf den Zweck zurück, statt die Mail zu verlieren.
+- Jede Mailart im Katalog hat einen Vorgabe-Zweck; keine steht ohne da.
+
 ## 4. Wann es läuft
 
 Ein Auftrag `ScanForIntrusions`, jede Minute über den Zeitplan, auf der