Wizard: idempotenter WAN-Apply fuer DHCP-Client/PPPoE (Bug 21)

Wizard erneut auf einem Interface durchlaufen, das schon einen
DHCP-Client hat (hier: aus einer zurueckgespielten Sicherung), scheiterte
live mit "failure: dhcp-client on that interface already exists" -
WanConfig.buildCommands() erzeugt fuer DHCP-Client/PPPoE immer .add, ohne
vorher zu pruefen, ob auf dem Interface schon einer existiert.

Fix: SetupViewModel.applyIdempotently faengt einen .add-Fehlschlag auf
/ip dhcp-client bzw. /interface pppoe-client ab und wiederholt ihn als
.set (nach "interface" gematcht) - bewusst nur fuer diese zwei Menues
mit "maximal ein Eintrag pro Interface"-Semantik, nicht generell fuer
jedes .add (z.B. /ip address erlaubt legitim mehrere Adressen pro
Interface).

Gefunden beim Versuch, M8 (Netzwerk-Isolation) live durchzutesten -
dieser Test selbst ist noch nicht abgeschlossen, naechste Session dort
weitermachen (siehe HANDOFF.md Naechste Schritte Punkt 1).

HANDOFF.md/CHATLOG.md aktualisiert: Bug 21, Sessionende-Stand.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CTgRxJTzaQwaRkngbaE1GJ

HANDOFF.md

@@ -56,6 +56,17 @@ Farbwerte, alles adaptive System-Farben) — vom Nutzer live bestätigt.
 Release-Build unter `/Applications/RouterOS Assistant.app` ist auf
 aktuellem Stand.
 
+**Zum Sessionende:** M8-Hardware-Test (Netzwerk-Isolation) begonnen —
+voller Wizard-Durchlauf über den Experte-Modus, WAN neu einrichten.
+Dabei Bug 21 gefunden: der Wizard-Apply nutzte für WAN-DHCP-Client/PPPoE
+immer `.add`, was auf einem bereits konfigurierten Interface (hier: aus
+der zurückgespielten Sicherung) mit "failure: dhcp-client on that
+interface already exists" scheiterte. Fix: `SetupViewModel.
+applyIdempotently` versucht bei `.add` auf `/ip dhcp-client` oder
+`/interface pppoe-client` nach einem Fehlschlag automatisch `.set`
+(nach "interface" gematcht) — deployt, **aber der eigentliche
+M8-Isolationstest selbst ist noch nicht zu Ende geführt/verifiziert**,
+das ist der erste Schritt für die nächste Session.
 ## Ziel
 
 Native macOS-App (SwiftUI), die Laien per geführtem Interview-Wizard durch
@@ -378,6 +389,19 @@ erreichen (siehe Bug 1 unten).
     Singleton-Menü, nicht nur `/system routerboard` — der generische
     Lese-Pfad wird von Übersicht-, Geräte- und Experte-Tab gemeinsam
     genutzt.
+21. **Wizard-WAN-Apply war nicht idempotent** — Wizard erneut auf einem
+    Interface durchlaufen, das schon einen DHCP-Client hat (hier: aus
+    einer zurückgespielten Sicherung), scheiterte live mit "failure:
+    dhcp-client on that interface already exists". `WanConfig.
+    buildCommands()` erzeugt für DHCP-Client/PPPoE immer `.add`, ohne
+    vorher zu prüfen, ob auf dem Interface schon einer existiert. Fix:
+    `SetupViewModel.applyIdempotently` fängt einen `.add`-Fehlschlag auf
+    `/ip dhcp-client`/`/interface pppoe-client` ab und wiederholt ihn als
+    `.set` (nach "interface" gematcht) — bewusst nur für diese zwei
+    Menüs mit "maximal ein Eintrag pro Interface"-Semantik, nicht generell
+    für jedes `.add` (z.B. `/ip address` erlaubt legitim mehrere
+    Adressen pro Interface). **Noch nicht erneut live getestet**, siehe
+    Nächste Schritte.
 
 **Lehren:** Citadel/NIOSSH-Fehler immer mit `String(describing:)` loggen,
 nie `.localizedDescription`. Jede View, die ein ObservableObject aus einem
@@ -741,11 +765,16 @@ beim Ändern die RouterOS-Suffix-Form zurück) — angewendet auf DHCP-Server
 
 ## Nächste Schritte
 
-1. Den kompletten Wizard einmal neu durchlaufen (WAN/LAN/VLAN/WLAN/
-   Firewall) auf dem werksresetteten hEX und dabei das Firewall-Ergebnis
-   mit korrektem WAN-Port per `/ip firewall filter print` /
-   `/ip firewall nat print` kontrollieren (bisher nur die Interface-
-   Auswahl nach dem Parser-Fix bestätigt, kein erneuter Apply).
+1. **In Arbeit, hier weitermachen:** kompletter Wizard-Durchlauf
+   (WAN/LAN mit zwei Interfaces ether2+ether3, eins isoliert/Firewall)
+   über den Experte-Modus — kombiniert M8-Hardware-Test (Netzwerk-
+   Isolation) mit diesem Punkt. Wurde in dieser Session begonnen, brach
+   beim WAN-Schritt mit Bug 21 ab (jetzt gefixt, deployt, aber
+   **ungetestet**). Nach erneutem Durchlauf: Firewall-Ergebnis mit
+   korrektem WAN-Port UND die Isolations-Regeln per
+   `/ip firewall filter print` kontrollieren, plus praktisch testen
+   (iMac ↔ Laptop sollten sich nicht erreichen, Internet für beide
+   schon).
 2. WLAN (M5) an einem Gerät mit echtem WLAN-Chip nachholen.
 3. Rest von M7: Fehlerzustände/Politur, REST-Schreibtest an einem Gerät
    mit aktivem `www-ssl`.