M25: Einrichten-Wizard-Politur + SSH-Trust-Persistenz endlich verifiziert

- WAN-Schritt: fehlenden "Zurück"-Button ergänzt (beide Modi)
- "Abbrechen"/"Jetzt sichern" prominent gemacht (wie "Neu scannen")
- LAN-/VLAN-Schritt: Adressfelder starten leer, nur Format-Beispiel im
  Feld sichtbar statt vorbelegter Werte. VlanStepView bekam dafür eine
  Validierungssperre auf "Weiter" (fehlte bisher, war ok solange
  Defaults immer gültig waren). Zwei Tests entsprechend angepasst.
- SSH-Host-Key-Trust aus M24 hatte sich entgegen der Live-Bestätigung
  nie tatsächlich persistiert (defaults read zeigte leeren Schlüssel,
  Ursache ungeklärt) — betraf BackupServices dedizierte SSH-Verbindung
  beim ersten Experte-Tab-Schreibversuch pro Sitzung. Erneut über den
  bestehenden Trust-Dialog bestätigt, diesmal per defaults read
  verifiziert statt nur der UI-Bestätigung vertraut.

Alles live bestätigt.

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

HANDOFF.md

@@ -1481,6 +1481,42 @@ Zeitpunkt bereits verbunden ist, würden dieselben dedizierten Dienste
 wieder wortlos nichts tun, ohne Hinweis auf die Ursache — siehe
 "Nächste Schritte".
 
+**M25: Einrichten-Wizard-Politur** (2026-09-16, mehrere kleine
+Nutzerwünsche in einer Runde):
+
+- **WAN-Schritt: "Zurück"-Button ergänzt** — fehlte seit jeher (nur
+  "Weiter"), in beiden Modi, fiel im Experte-Modus nur eher auf, da
+  dort mehr Schritte durchgeklickt werden. Live bestätigt.
+- **"Abbrechen" (Einrichten) + "Jetzt sichern" (Sicherungen) prominent
+  gemacht** — dieselbe `.buttonStyle(.borderedProminent)`-Behandlung
+  wie zuvor schon "Neu scannen" (Bug: "leicht zu übersehen"), jetzt
+  konsequent auf alle **einzelnen, gleichrangigen** Toolbar-Aktions-
+  buttons der App angewendet. Übersicht-Tabs Toolbar-Gruppe (Zoom/
+  Zurücksetzen/Aktualisieren, mehrere gleichrangige Buttons
+  nebeneinander) bewusst ausgenommen — dort würde durchgängiges
+  Prominent-Styling überladen wirken, ein anderes UI-Muster als "eine
+  einzelne leicht übersehene Hauptaktion".
+- **LAN- und VLAN-Schritt: Adressfelder starten leer** (Nutzerwunsch:
+  "die auszufüllenden Felder leer lassen, nur Beispiele zeigen ...
+  so sieht man das Schema dahinter") — `LanDhcpConfig`/`VlanEntry`
+  hatten bisher konkrete Default-Werte (z.B. "192.168.88.1/24" bzw.
+  eine aus der VLAN-ID abgeleitete Adresse); da jedes TextField-Label
+  ("Router-Adresse (z.B. 192.168.88.1/24)") ohnehin als Platzhalter
+  dient, sobald das Feld leer ist, versteckte ein vorbelegter Wert
+  dieses Beispiel bisher komplett. Betrifft beide Modi (LAN-Schritt
+  wird von Einfach und Experte geteilt). `interfaceName` (Picker) und
+  `leaseTimeHours` (Stepper) bleiben unverändert vorbelegt — beides
+  Auswahl-UI ohne "Beispiel tippen"-Konzept. Notwendige Begleitänderung:
+  `VlanStepView`s "Weiter" hatte bisher **keine** Validierungssperre
+  (unnötig, solange die Defaults immer gültig waren) — jetzt analog zum
+  längst vorhandenen `LanStepView`-Muster ergänzt, sonst hätte ein leer
+  gelassenes VLAN-Feld einen Befehl mit leeren Argumenten zum Router
+  geschickt. Zwei Tests entsprechend angepasst
+  (`testDefaultAddressesStartEmptyForExamplePlaceholder` ersetzt die
+  alte Ableitungs-Prüfung; `testLanDhcpCommandsCoverAddressPoolServerAndNetwork`
+  setzt die Adressfelder jetzt explizit statt sich auf Modell-Defaults
+  zu verlassen). Live bestätigt ("gut soweit").
+
 ## Nächste Schritte
 
 1. ~~M16: restliche `RouterOSSchemaCatalog.swift`-Sektionen übersetzen~~,
@@ -1645,15 +1681,38 @@ wieder wortlos nichts tun, ohne Hinweis auf die Ursache — siehe
     `UpdateService`/`FactoryResetService` haben keinen eigenen
     UI-Bestätigungspfad für einen neuen SSH-Host-Key, nur
     `ConnectionService.connect`s SSH-*Fallback* zeigt den Dialog — und
-    der wird nie erreicht, solange REST erfolgreich verbindet. Ein
-    künftiger Host-Key-Wechsel (z.B. nach einem weiteren Werksreset)
-    würde also wieder zu wortlos leeren Ergebnissen führen (leere
-    Traffic-Anzeige, fehlschlagende Backups, etc.), ohne erkennbaren
-    Grund in der UI. Mögliche Fixes: diese Dienste bei
-    `untrustedSSHHostKey` einen eigenen Bestätigungsdialog zeigen
-    lassen, oder `ConnectionService` beim Verbinden zusätzlich (nicht
-    nur im Fallback-Fall) einmal den SSH-Host-Key prüfen/bestätigen
-    lassen, unabhängig davon, ob REST erfolgreich war.
+    der wird nie erreicht, solange REST erfolgreich verbindet. Mögliche
+    Fixes: diese Dienste bei `untrustedSSHHostKey` einen eigenen
+    Bestätigungsdialog zeigen lassen, oder `ConnectionService` beim
+    Verbinden zusätzlich (nicht nur im Fallback-Fall) einmal den
+    SSH-Host-Key prüfen/bestätigen lassen, unabhängig davon, ob REST
+    erfolgreich war. **Tatsächlich so eingetreten (2026-09-16):** beim
+    ersten Experte-Tab-Schreibversuch einer neuen Sitzung (`ensureSessionBackup`,
+    läuft einmal pro Verbindung vor der ersten Änderung) schlug
+    `BackupService`s eigene, dedizierte SSH-Verbindung mit
+    "Unbekannter SSH-Schlüssel" fehl — sichtbar nur als roter
+    `applyError`-Text im Experte-Formular, ohne erkennbaren
+    Zusammenhang zum eigentlichen SSH-Host-Key-Problem. Der erste
+    Trust-Fix-Versuch von vorhin (M24-Nebenbefund) hatte sich entgegen
+    der Live-Bestätigung des Nutzers ("vertraut, verbunden per SSH")
+    **nicht** tatsächlich persistiert — `defaults read
+    com.focus72.RouterOSAssistant
+    RouterOSAssistant.TrustedSSHHostKeyFingerprints` zeigte einen
+    komplett fehlenden Schlüssel, obwohl der strukturell identische,
+    nachweislich funktionierende REST-Zertifikat-Trust
+    (`TrustedCertificateFingerprints`) im selben Preferences-Bereich
+    korrekt vorhanden war. Ursache dafür bleibt ungeklärt — der Code-Pfad
+    (`ConnectViewModel.trustSSHHostKeyAndRetry` →
+    `ConnectionService.trustCurrentSSHHostKeyAndRetry` →
+    `SSHHostKeyTrustStore.trust`) ist exakt symmetrisch zum
+    funktionierenden Zertifikat-Pfad, kein Unterschied im Code
+    gefunden. Fix diesmal per `www-ssl` erneut kurz deaktiviert,
+    Trust-Dialog erneut bestätigt, **und diesmal per `defaults read`
+    direkt verifiziert, dass der Fingerprint wirklich persistiert wurde**
+    (war er) — DHCP-Netzwerk-Anlage danach live erfolgreich. Falls
+    dieses Symptom nochmal auftritt: zuerst per `defaults read` prüfen,
+    ob der Trust wirklich gespeichert wurde, nicht nur der UI-Bestätigung
+    vertrauen.
 
 Gitea-Remote `origin` ist eingerichtet und wird laufend gepusht (siehe
 oben) — dieser Hinweis war veraltet, korrigiert am 2026-09-15.