Docs: Bonding (M10) erstmals gegen echte Hardware verifiziert

hAP lite, ether3+ether4, mode=active-backup: bond1 korrekt angelegt
und laufend. App meldete beim zweiten Anlege-Versuch einen Fehler
(Exit-Code 126, kein Klartext), Router-Zustand zeigte aber Erfolg —
vermutlich kurz abgerissene SSH-Verbindung durch Interface-
Neuinitialisierung, dokumentiert statt weiterverfolgt. Kein Code
geändert, nur HANDOFF/CHATLOG.

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

CHATLOG.md

@@ -1082,3 +1082,17 @@ Test, WLAN/Bonding/PPPoE-Live-Tests).
   eingerichteten WLAN. Damit M5 (WLAN-Schritt) und der WLAN-Teil von
   M10 (Experte-Tab-Schemas) erstmals vollständig gegen Hardware
   bestätigt — vorher nur der "kein WLAN"-Zweig getestet.
+
+## Session: Bonding erstmals gegen echte Hardware verifiziert (M10)
+
+- "Bonding testen" (hAP lite, ether3+ether4 frei) → Experte-Tab →
+  Interfaces → Bonding, `mode=active-backup`. Erster Versuch schlug
+  erwartungsgemäß fehl ("ether3 already in bridge" — Ports waren noch
+  LAN-Bridge-Mitglieder). Nach Entfernen aus der Bridge zweiter
+  Versuch: App meldete einen Fehler ("Exit-Code 126" ganz ohne
+  Klartext), `/interface bonding print` am Router zeigte aber `bond1`
+  bereits korrekt angelegt und laufend — vermutlich eine durch die
+  Interface-Neuinitialisierung kurz abgerissene SSH-Verbindung, die
+  die App fälschlich als Fehler wertete. Bonding selbst funktioniert
+  einwandfrei. "reicht, doku aktualisieren und committen, aber nicht
+  deployen" → HANDOFF.md aktualisiert, Commit ohne Release-Deploy.

HANDOFF.md

@@ -1636,8 +1636,31 @@ verallgemeinert** (2026-09-16, beim Live-Test von M26 gefunden):
    manuell durchklicken — M10s Experte-Tab wurde bereits vom Nutzer
    bestätigt (siehe oben), der Moduswechsel im Wizard noch nicht.
 4. M10: ~~WLAN-Schemas (an Gerät mit WLAN-Chip)~~ — erledigt
-   (2026-09-17, hAP lite). Bonding, PPPoE-Client (mit echten oder
-   Test-ISP-Zugangsdaten) weiterhin nicht gegen Hardware verifiziert.
+   (2026-09-17, hAP lite). ~~Bonding~~ — erledigt (2026-09-17, hAP
+   lite, `ether3`+`ether4`, `mode=active-backup`): `/interface bonding
+   add` schlug beim ersten Versuch erwartungsgemäß fehl ("ether3
+   already in bridge" — beide Ports waren noch LAN-Bridge-Mitglieder,
+   RouterOS erlaubt einen Port nicht gleichzeitig in Bridge und
+   Bonding; kein App-Bug). Nach Entfernen aus der Bridge und erneutem
+   Versuch meldete die App einen Fehler ("Exit-Code 126", ganz ohne
+   RouterOS-Klartext — ungewöhnlich, normale RouterOS-CLI-Fehler
+   liefern Text, siehe erster Versuch), aber `/interface bonding
+   print` am Router zeigte `bond1` bereits korrekt angelegt und
+   laufend. Vermutlich eine durch die Interface-Neuinitialisierung
+   beim Bridge-Entfernen kurz abgerissene SSH-Verbindung, die die App
+   fälschlich als Fehler interpretierte, obwohl der Befehl durchlief
+   — derselbe Grundsatz wie bei Bug 10/17 ("leere/fehlerhafte Antwort
+   ist kein Beweis, dass nichts passiert ist"), hier aber in die
+   andere Richtung: ein gemeldeter Fehler ist kein Beweis, dass nichts
+   passiert ist. Nicht weiter codeseitig verfolgt (einmalig
+   beobachtet, kein reproduzierbarer Bug-Report nötig) — bei erneutem
+   Auftreten zuerst immer den echten Router-Zustand per `print`
+   verifizieren, nicht der App-Fehlermeldung allein vertrauen.
+   PPPoE-Client weiterhin nicht gegen Hardware verifiziert — am hAP
+   lite nicht testbar (2026-09-17: Gerät hängt hinter einem bereits
+   konfigurierten Router, kein direkter PPPoE-fähiger WAN-Uplink
+   verfügbar); bräuchte ein
+   Testgerät direkt am Modem/ISP-Anschluss mit echten Zugangsdaten.
 5. ~~Dauer-Editor (`RouterOSFieldSchema.Kind.duration`) auch auf weitere
    Zeitwert-Felder anwenden~~ — erledigt (2026-09-16): WireGuard-Peer
    "Keepalive" (Label-Zusatz "(Sekunden)" entfernt, Stepper zeigt Einheit