Bug 25/26: geleerte Felder blieben bestehen, Route-Bearbeiten scheiterte an nur-lesbarem Feld

Beide Bugs in ExpertViewModel.pendingCommand, betreffen Experte-Tab
direkt (nicht nur den neuen Übersicht-Bearbeiten-Weg):

- Bug 25: ein geleertes Textfeld (z.B. Kommentar löschen) wurde beim
  Speichern aus den Argumenten gefiltert statt explizit als "" gesendet
  — RouterOS' `set` ändert nur übergebene Parameter, ein weggelassener
  bleibt unangetastet statt geleert. Fix: Feld bleibt im Argument-Set,
  wenn es vorher einen Wert hatte; RouterOSCommand's SSH-Zeilen-Rendering
  gibt einen leeren Wert jetzt als `""` statt als nacktes `feld=` aus.
- Bug 26: eine Route bearbeiten (z.B. nur Kommentar ändern) scheiterte
  mit "bad parameter immediate-gw" — dieses von RouterOS mitgelieferte,
  nur lesbare/berechnete Feld landete unkuratiert in den freien
  "Weiteren Parametern" und wurde bei jedem Speichern blind
  mitgeschickt. Fix: ein unkuratiertes Feld wird nur noch gesendet, wenn
  sein Wert sich gegenüber dem ursprünglich geladenen Item tatsächlich
  geändert hat.

54 Unit-Tests grün (neue ExpertViewModelTests + eine Ergänzung in
RouterOSCommandBuilderTests).

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

HANDOFF.md

@@ -528,7 +528,26 @@ selbst als ungültig ("in/out-interface matcher not possible when
 interface is slave - use master instead"), live an `ether4` bestätigt;
 `DhcpServerCommandBuilder` stellt seitdem ein `/interface bridge port
 remove [find interface=<name>]` voran (übersprungen für "bridge"
-selbst).
+selbst). **Ein geleertes Textfeld (z.B. Kommentar) blieb nach dem
+Speichern unverändert bestehen** (Bug 25) — `pendingCommand` filterte
+alle leeren `formValues` grundsätzlich aus den Argumenten heraus, RouterOS'
+`set` ändert aber nur explizit übergebene Parameter, ein weggelassener
+bleibt unangetastet statt geleert. Fix: ein Feld bleibt im Argument-Set,
+wenn es vorher einen Wert hatte (jetzt als `feld=""` explizit geleert);
+zusätzlich musste `RouterOSCommand`s SSH-Zeilen-Rendering einen leeren
+Wert als `""` statt als nacktes `feld=` ausgeben. **Bearbeiten einer
+Route (z.B. nur den Kommentar ändern) scheiterte mit "bad parameter
+immediate-gw"** (Bug 26) — RouterOS liefert bei `/ip route print` u.a.
+das berechnete, nur lesbare Feld `immediate-gw` mit; da dieses Feld im
+Route-Schema nicht kuratiert ist, landete es unverändert in den freien
+"Weitere Parameter" und wurde bei *jedem* Speichern blind mitgeschickt —
+RouterOS lehnt `immediate-gw` beim `set` als ungültigen Parameter ab und
+bricht dadurch die komplette Änderung ab, auch wenn nur ein unrelated
+Feld wie der Kommentar geändert wurde. Fix: ein unkuratiertes Feld wird
+nur noch mitgeschickt, wenn sein Wert sich gegenüber dem ursprünglich
+geladenen Item tatsächlich geändert hat (oder neu hinzugefügt wurde) —
+betrifft nicht nur Routen, sondern jedes Menü mit berechneten/nur
+lesbaren Feldern im generischen Lese-Pfad.
 
 ## `xcodebuild test` hängt — Gatekeeper, kein Code-Bug
 
@@ -812,8 +831,13 @@ Bezug zu einem Router-Item).
 
 **Live gegen Hardware verifiziert** — Nutzer bestätigte Kommentar-
 Änderung an einer Firewall-Regel über den neuen Bearbeiten-Weg
-("funktioniert"). Alle 59 Unit-Tests grün, inkl. neuer Tests für
-`editTarget` (`OverviewGraphTests.
+("funktioniert"). Direkt danach beim Weitertesten zwei echte Bugs in der
+gemeinsamen Bearbeiten-Logik gefunden (Bug 25, 26 — siehe Bug-Liste
+oben): geleertes Textfeld blieb bestehen, Route-Bearbeiten scheiterte an
+einem nur-lesbaren Feld (`immediate-gw`). Beide betreffen `ExpertViewModel.
+pendingCommand` und damit **auch den Experte-Tab direkt**, nicht nur den
+neuen Übersicht-Weg — gefixt, alle 54 Unit-Tests grün (inkl. neuer
+`ExpertViewModelTests` und `OverviewGraphTests.
 testEditableNodesCarryTheirRouterOSMenuAndItemID`).
 
 ## Stand der Milestones
@@ -915,9 +939,12 @@ testEditableNodesCarryTheirRouterOSMenuAndItemID`).
   verdrängt) plus neue Fähigkeit: Knoten (IP-Adresse, Pool, DHCP-Server/
   -Netzwerk/-Client, Route, Firewall-Filter-/NAT-Regel, WireGuard-Peer)
   direkt über dieselbe Sheet wie im Experte-Tab bearbeiten und
-  zurückschreiben. **Live gegen Hardware verifiziert** — Nutzer
-  bestätigte Kommentar-Änderung an einer Firewall-Regel über den neuen
-  Weg ("funktioniert").
+  zurückschreiben. Dabei zwei Bugs in der gemeinsamen Bearbeiten-Logik
+  gefunden+gefixt (Bug 25, 26 — betreffen auch den Experte-Tab direkt):
+  geleertes Feld blieb bestehen statt geleert zu werden, Route-Bearbeiten
+  scheiterte an einem nur-lesbaren Feld (`immediate-gw`). **Live gegen
+  Hardware verifiziert** — Nutzer bestätigte Kommentar-Änderung an einer
+  Firewall-Regel über den neuen Weg ("funktioniert").
 
 ## Nächste Schritte