refactor(domains): Einstellung Standard-Nameserver entfernt, Doku angepasst (h3t)

- Spalte DomainsConfig.defaultNameServers per Migration 20261008160000 entfernt
- Feld in Einstellungen/Status (API, DTO, Typen) und Karte im Web entfernt
- Anleitungen und CHANGELOG: Nameserver kommen aus AutoDNS

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

docs/anleitung-administration.md

@@ -360,11 +360,11 @@ Das Modul „Nextcloud-Status“ (Gruppe Infrastruktur) aktivieren Sie wie jedes
 
 Das Modul „Domains“ (Gruppe Domains) aktivieren Sie wie jedes Modul im Marktplatz; wer es nutzen soll, bekommt die Freigabe „Benutzen“. **Die Anbindung einrichten, Kunden und Kontakte anlegen und Domains registrieren** dürfen Administratoren und Benutzer mit der Freigabestufe „Verwalten“ – vergeben Sie diese Stufe nur an Personen, denen Sie Bestellungen auf Ihre Kosten zutrauen, denn eine Registrierung im Live-System ist verbindlich und kostenpflichtig.
 
-- **Eigener AutoDNS-Benutzer:** Legen Sie bei AutoDNS einen eigenen Benutzer für Tessera an, **ohne Zwei-Faktor-Anmeldung** – Tessera meldet sich mit Benutzername, Passwort und der Kontextnummer an, einen Zusatzcode kann es nicht eingeben. Der Benutzer braucht die Rechte, Domains und Kontakte zu lesen sowie Kontakte anzulegen und Domains zu registrieren.
+- **Eigener AutoDNS-Benutzer:** Legen Sie bei AutoDNS einen eigenen Benutzer für Tessera an, **ohne Zwei-Faktor-Anmeldung** – Tessera meldet sich mit Benutzername, Passwort und der Kontextnummer an, einen Zusatzcode kann es nicht eingeben. Der Benutzer braucht die Rechte, Domains und Kontakte zu lesen sowie Kontakte anzulegen und Domains zu registrieren; außerdem muss er sein eigenes Benutzerprofil lesen dürfen (daraus liest Tessera die Standard-Nameserver).
 - **Kontext je System:** Tragen Sie unter Domains → Einstellungen für das Demo-System und das Live-System je Benutzername, Passwort und Kontext ein. Beim Live-System ist der Kontext in der Regel **4** (das Feld ist damit vorbelegt). Für das Demo-System nennt InterNetX den Wert; er steht nicht fest und ist deshalb frei eintragbar. Das Passwort wird verschlüsselt gespeichert und nie wieder angezeigt; lassen Sie das Feld später leer, um es zu behalten.
 - **Mit dem Demo-System beginnen:** Neue Installationen laufen im Demo-System, dort entstehen keine echten Registrierungen. Probieren Sie zuerst dort alles aus. Der Wechsel auf das Live-System (Einstellungen → System) verlangt eine ausdrückliche Bestätigung; danach zeigt die Kennzeichnung oben auf der Seite „Live-System – Registrierungen kosten Geld“. Für jedes System gelten eigene Zugangsdaten, eigene Kontakt-Zuordnungen und eigene Aufträge – ein Entwurf aus dem Demo-System kann nie im Live-System bestellt werden.
 - **Verbindung testen:** Der Knopf schickt genau einen Anmeldeversuch an AutoDNS. Klicken Sie bei einer Fehlermeldung nicht wiederholt: **Mehrere falsche Anmeldungen hintereinander können den AutoDNS-Benutzer sperren.** Prüfen Sie erst Benutzername, Passwort und Kontext, speichern Sie, und testen Sie dann einmal.
-- **Standard-Nameserver:** Unter „Standard-Nameserver“ (zwei bis sechs) hinterlegen Sie die Nameserver, die bei jeder Registrierung vorausgefüllt werden. Sie **müssen bei Ihrem Anbieter bereits eingerichtet sein**: Für `.de`-Domains prüft die Registry (DENIC) die Nameserver bei der Registrierung, und eine Registrierung mit nicht eingerichteten Nameservern scheitert („Fehlgeschlagen“).
+- **Nameserver kommen aus AutoDNS:** Tessera hat keine eigene Nameserver-Einstellung. Bei jeder Registrierung liest es die Standard-Nameserver aus dem AutoDNS-Benutzerprofil des in den Einstellungen eingetragenen AutoDNS-Benutzers (auch von einem übergeordneten Benutzer geerbte Werte) und verwendet sie unverändert und in der dort hinterlegten Reihenfolge. Hinterlegen Sie dort mindestens zwei Nameserver. Sie **müssen eingerichtet sein**: Für `.de`-Domains prüft die Registry (DENIC) die Nameserver bei der Registrierung, und eine Registrierung mit nicht eingerichteten Nameservern scheitert („Fehlgeschlagen“). Findet Tessera keine Nameserver oder kann es sie nicht lesen, zeigt der Reiter „Registrieren“ einen Hinweis, und die Registrierung ist nicht möglich.
 - **Netzwerk:** Der API-Container braucht ausgehenden Zugriff (https) auf `api.autodns.com` (Live) und `api.demo.autodns.com` (Demo). Die Adressen sind fest eingebaut und nicht änderbar; Zertifikate werden geprüft, Weiterleitungen nicht befolgt.
 - **Abfragegrenze:** AutoDNS erlaubt etwa drei Anfragen pro Sekunde und IP-Adresse. Tessera hält das ein (höchstens eine Anfrage alle 350 Millisekunden, Listen seitenweise, ein Zwischenspeicher von einer Minute) und wiederholt nie selbstständig eine Anfrage. Listen zeigen höchstens die ersten 2000 Einträge.
 - **Keine Doppelbestellung:** Jede Registrierung wird höchstens einmal an AutoDNS geschickt. Bei Zeitüberschreitung oder Verbindungsabbruch steht der Auftrag auf „Ergebnis ungeklärt“ und wird beim nächsten Abgleich (Reiter „Aufträge“) mit AutoDNS verglichen. Ein unklarer Auftrag lässt sich erst verwerfen, nachdem dieser Abgleich ohne Fund durchgelaufen ist.

docs/anleitung-anwender.md

@@ -174,7 +174,7 @@ Mit dem Modul „Domains“ (Gruppe **Domains**) verwalten Sie Ihre Domains bei
 **Eine Domain registrieren** (Reiter „Registrieren“, nur mit „Verwalten“):
 
 1. Domain eingeben und **„Verfügbarkeit prüfen“**. Nur „frei“ lässt sich registrieren; der Preis für ein Jahr wird angezeigt, sofern AutoDNS ihn nennt.
-2. Für **Inhaber, Admin-Kontakt, technischen Kontakt und Zonenkontakt** je einen Kontakt wählen. Admin-, Technik- und Zonenkontakt sind vorausgewählt (Admin wie der Inhaber, Technik und Zone wie der erste Kontakt Ihrer eigenen Firma, sonst wie der Inhaber) und lassen sich ändern. Die **Nameserver** sind aus den Einstellungen vorausgefüllt; es sind zwei bis sechs nötig.
+2. Für **Inhaber, Admin-Kontakt, technischen Kontakt und Zonenkontakt** je einen Kontakt wählen. Admin-, Technik- und Zonenkontakt sind vorausgewählt (Admin wie der Inhaber, Technik und Zone wie der erste Kontakt Ihrer eigenen Firma, sonst wie der Inhaber) und lassen sich ändern. Darunter sehen Sie – nur zur Kontrolle – die in AutoDNS als Standard hinterlegten **Nameserver**, in der dort hinterlegten Reihenfolge. Sie lassen sich nur in AutoDNS ändern. Sind dort keine hinterlegt, erscheint ein Hinweis, und die Registrierung ist gesperrt.
 3. **„Zusammenfassung anzeigen“** und alles prüfen: System, Domain, Laufzeit (ein Jahr), Preis, Kontakte, Nameserver.
 4. Das Häkchen zur Bestätigung setzen und **„Jetzt verbindlich registrieren“** klicken. Im Live-System kostet das Geld.
 

docs/mandantentrennung-zugriffsklassifikation.md

@@ -898,7 +898,7 @@ werden.
 | apps/api/src/domains/domains-directory.service.ts | domainsCustomer | muss-mandantengebunden | gebunden | **quick-261008-dts (Aufgabe 2):** neu — Kunden des Moduls Domains (Name je Organisation eindeutig, Markierung „eigene Firma“, höchstens eine). `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20261008120000) — Organisationsdaten. Bewusst KEINE `system_read_policy`. Acht Rohtreffer über `const tenantPrisma = forTenant(this.prisma, tenantId)`, je Methode ein eigener Klient; jeder `where` trägt `tenantId` (auch `updateMany`/`deleteMany` über `id` UND `tenantId`, damit eine fremde Id 0 Treffer liefert und als 404 endet). Kein `include`/relationales `select`. |
 | apps/api/src/domains/domains-directory.service.ts | domainsContactAssignment | muss-mandantengebunden | gebunden | **quick-261008-dts (Aufgabe 2):** neu — Zuordnung AutoDNS-Kontakt → Kunde. Das System (Demo/Live) ist Teil des Schlüssels (`@@unique([tenantId, environment, autodnsContactId])`), weil Kontakt-Nummern beider Systeme zwangsläufig kollidieren; jede Abfrage filtert auf das AKTIVE System. `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20261008120000). Bewusst KEINE `system_read_policy`. Fünf Rohtreffer über `tenantPrisma` (`findMany`, `count`, zweimal `upsert`, `deleteMany`); der Fremdschlüssel auf den Kunden steht auf `Restrict`, ein Kunde mit Zuordnungen wird nicht gelöscht. Kein `include`/relationales `select`. |
 | apps/api/src/domains/domains-orders.service.ts | domainsOrder | muss-mandantengebunden | gebunden | **quick-261008-dts (Aufgabe 3):** neu — Registrierungsaufträge des Moduls Domains (Entwurf, Anspruch, Ergebnis, Prüfspur mit Benutzer und Zeitpunkt der Bestätigung). `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20261008120000) — Organisationsdaten. Bewusst KEINE `system_read_policy`: kein Hintergrunddienst, der Stand wird beim Öffnen des Reiters abgeglichen. Fünfzehn Rohtreffer über `tenantPrisma`, je Methode ein eigener Klient; jeder `where` trägt `tenantId`, fremde Nummern enden als 404. Der Anspruch ist ein `updateMany` mit `status: 'DRAFT'` und dem aktiven System in der Bedingung; erst bei Zähler 1 geht `POST /domain` hinaus (Geld, höchstens einmal). Die Eindeutigkeit offener Aufträge je Domain und System sichert die Spalte `openKey` (`@@unique([tenantId, environment, openKey])`). Kein `include`/relationales `select`. |
-| apps/api/src/domains/domains-settings.service.ts | domainsConfig | muss-mandantengebunden | gebunden | **quick-261008-dts:** neu — Einstellungen des Moduls Domains (AutoDNS), eine Zeile je Organisation (Singleton): aktives System (Demo/Live), getrennte Zugänge je System mit AES-verschlüsseltem Passwort (CryptoService, nie an den Client zurückgegeben), Standard-Nameserver. `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20261008120000) — Einstellungen der Organisation, nicht persönliche Daten eines Benutzers. Bewusst KEINE `system_read_policy`: kein Hintergrunddienst, der Auftragsstatus wird beim Öffnen der Seite abgefragt. Zwei Rohtreffer über `const tenantPrisma = forTenant(this.prisma, tenantId)` (`loadRow` `findUnique`, `saveSettings` `upsert`); `where` trägt `tenantId`. |
+| apps/api/src/domains/domains-settings.service.ts | domainsConfig | muss-mandantengebunden | gebunden | **quick-261008-dts:** neu — Einstellungen des Moduls Domains (AutoDNS), eine Zeile je Organisation (Singleton): aktives System (Demo/Live), getrennte Zugänge je System mit AES-verschlüsseltem Passwort (CryptoService, nie an den Client zurückgegeben). Spalte für Standard-Nameserver mit quick-261008-h3t entfernt (Migration 20261008160000). `tenantId`-Spalte vorhanden, Regel `tenant_isolation_policy` OHNE Benutzerdimension (Migration 20261008120000) — Einstellungen der Organisation, nicht persönliche Daten eines Benutzers. Bewusst KEINE `system_read_policy`: kein Hintergrunddienst, der Auftragsstatus wird beim Öffnen der Seite abgefragt. Zwei Rohtreffer über `const tenantPrisma = forTenant(this.prisma, tenantId)` (`loadRow` `findUnique`, `saveSettings` `upsert`); `where` trägt `tenantId`. |
 | apps/api/src/nextcloud-status/nextcloud-alert.service.ts | nextcloudAlertSubscription | muss-mandantengebunden | gebunden | **quick-261002-kxc:** neu — die persönliche Glocke „Benachrichtigen“ je Benutzer und Cloud. `tenantId`- und `userId`-Spalte vorhanden, Regel `tenant_isolation_policy` MIT Benutzerdimension (Migration 20261002170000, Form aus `Reminder`), bewusst OHNE `system_read_policy` — die Tabelle wird nie im Systemkontext gelesen. Jeder Zugriff läuft an den Mandanten gebunden: `subscribe`/`unsubscribe`/`subscribedInstanceIds` über `forTenant(this.prisma, tenantId, userId)` (Benutzer aus dem Token, nie aus dem Body), der Versand (`notifySubscribers`) über `forTenant(this.prisma, tenantId)` mit `where: { tenantId, instanceId }`; `listRecentAlerts` (Meldung in Tessera) liest nur die Abonnements des Aufrufers (`where: { tenantId, userId }`, Benutzer aus dem Token). |
 | apps/api/src/nextcloud-status/nextcloud-alert.service.ts | nextcloudInstance | muss-mandantengebunden | gebunden | **quick-261002-kxc:** `subscribe` prüft per `findFirst` mit `where: { id, tenantId }`, dass die Cloud dem Mandanten gehört (sonst 404); `evaluateAfterCheck` beansprucht den Übergang per `updateMany` mit `where: { id, tenantId, alertState }` VOR dem Mailversand (nur `count === 1` meldet, mehrere API-Instanzen und Neustarts melden nie doppelt). Beides an den Mandanten gebunden, kein Systemkontext. |
 | apps/api/src/nextcloud-status/nextcloud-alert.service.ts | user | muss-mandantengebunden | gebunden | **quick-261002-kxc:** `notifySubscribers` liest die Empfänger der Abonnements (`user.findMany` mit `where: { tenantId, id: { in } }`, nur skalare Felder E-Mail, Rolle, `isActive`), gebunden an den Mandanten der Cloud. Konto-Aktivität und Modulzugriff werden beim Senden erneut geprüft (nicht erst beim Einschalten der Glocke). |