Bug 37: SSH-Hostkey-Trust bei REST-Verbindungen proaktiv etablieren

Dedizierte SSH-Dienste (BackupService u.a.) sind der erste echte
SSH-Kontakt zu einem per REST verbundenen Router und trafen dort auf
einen unbestätigten Hostkey ohne Trust-UI (nur ReviewApplyView/
ExpertMenuDetailView-Fehlertext, kein Bestätigungsweg). Fix: nach
jedem erfolgreichen REST-Connect prüft ConnectionService den
SSH-Hostkey einmalig im Hintergrund und zeigt bei Bedarf denselben
Trust-Dialog wie der SSH-Fallback, ohne die aktive REST-Verbindung neu
aufzubauen. Live bestätigt.

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

HANDOFF.md

@@ -994,8 +994,13 @@ Unit-Tests grün (inkl. neuer `ExpertViewModelTests` und
   ("Signal Router"-Motiv).
 - 🔶 M7: Härtung — SSH-Hostkey-TOFU **fertig, gegen echte Hardware
   bestätigt** (inkl. neuem "Trennen"-Button im Verbinden-Tab, der dafür
-  nötig wurde). Fehlerzustände/Politur und REST-Schreibpfad-Verifikation
-  gegen ein Gerät mit aktivem `www-ssl` stehen noch aus.
+  nötig wurde). REST-Schreibpfad gegen `www-ssl` seit 2026-09-16 verifiziert
+  (Bug 30–32). Dabei zusätzlich Bug 37 gefixt: REST-Erstverbindungen
+  etablieren jetzt automatisch auch SSH-Trust im Hintergrund, statt dass
+  dedizierte SSH-Dienste (Backup u.a.) beim ersten Zugriff mit einem
+  unbestätigbaren Hostkey-Fehler dead-enden (live bestätigt, "passt").
+  Verbleibend: REST-Fehlerzustände bei Verbindungsabbruch mitten im Apply
+  noch nicht gezielt geprüft.
 - ✅ M8: Mehrere LAN-Interfaces mit eigenem DHCP + Netzwerk-Isolation
   (eigene Firewall-Regeln pro LAN/VLAN) — **live gegen Hardware
   verifiziert**, sowohl manuell (SSH) als auch über den App-Wizard
@@ -1802,7 +1807,31 @@ verallgemeinert** (2026-09-16, beim Live-Test von M26 gefunden):
     (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.
+    vertrauen. **Bug 37, richtig gefixt (2026-09-16):** genau dieses Symptom
+    erneut live reproduziert (neuer Testrouter, REST verbunden, erster
+    Wizard-Apply scheiterte mit "Unbekannter SSH-Schlüssel", reiner
+    `applyError`-Text ohne Bestätigungsmöglichkeit in `ReviewApplyView`).
+    Root Cause diesmal wirklich behoben statt nur umgangen: `ConnectionService.
+    connect` kehrt bei erfolgreichem REST-Connect sofort zurück, ohne je
+    einen SSH-Verbindungsversuch zu machen — der SSH-Host-Key dieses Hosts
+    wurde also nie geprüft/vertraut, `SSHHostKeyTrustStore` hatte schlicht
+    keinen Eintrag dafür. Dedizierte SSH-Dienste (`BackupService` u.a., s.o.)
+    sind aber der erste tatsächliche SSH-Kontakt zu diesem Host — treffen
+    dort auf einen komplett neuen, unbestätigten Schlüssel, aber `ReviewApplyView`/
+    `ExpertMenuDetailView` haben nur ein simples `.alert` mit "OK", keinen
+    Trust-Button. Fix: neues `ConnectionService.pendingSSHTrustFingerprint`
+    (getrennt von `state`) — nach jedem erfolgreichen REST-Connect prüft
+    `verifySSHTrust` einmalig per Wegwerf-`SSHTransport` den Host-Key im
+    Hintergrund; bei `untrustedSSHHostKey` wird der Fingerabdruck dort
+    abgelegt, `ConnectView` zeigt dafür denselben Trust-Dialog wie beim
+    reinen SSH-Fallback (`sshHostKeyFingerprint` liest jetzt beide Quellen),
+    Bestätigen ruft `trustPendingSSHHostKeyAndRetry()` (kein Reconnect nötig,
+    REST-Verbindung bleibt unberührt) statt `trustCurrentSSHHostKeyAndRetry`
+    (das reconnectet komplett neu, nur für den echten Fallback-Fall
+    gebraucht). Damit ist der Host-Key schon beim Verbinden bestätigt, lange
+    bevor Backup/Wizard-Apply/Experte-Tab ihn zum ersten Mal brauchen. Live
+    bestätigt ("passt") — REST-Connect zum Testrouter zeigte den Trust-Dialog
+    sofort, danach lief ein Wizard-Apply ohne den Dead-End-Fehler durch.
 14. ~~M26 (Seriennummer bei "Bekannte Router") noch live testen~~ —
     erledigt, siehe M27 oben (dabei zwei weitere Bugs gefunden und
     gefixt: geteilter Schlüsselbund-Eintrag, `/system routerboard`s