Fix 3 nicht funktionierende Alert-Dismiss-Buttons (M34)

README-Milestone-Nachcheck (Port-Konflikt-Prüfung/"Fertig"-Button)
deckte drei eigenständige Bugs derselben Klasse auf: Cancel/OK-Buttons
bei ReviewApplyViews Apply-Fehler-Alert, ConnectViews
Zertifikat-Alert und ConnectViews SSH-Hostkey-Alert taten nichts oder
zu wenig - der jeweilige Verbindungs-/Fehlerzustand blieb hängen,
der Dialog konnte nicht sauber verlassen werden.

Neue ConnectionService.cancelPendingTrustConfirmation() und
SetupViewModel.dismissApplyError(), alle drei Alerts korrekt
verdrahtet (Button-Action + Bindings-Setter fuer Tap-Outside/Esc).
Totes dismissPendingSSHTrust() entfernt. 1 neuer Regressionstest,
alle 102 Unit-Tests gruen.

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

bugs.md

@@ -245,3 +245,37 @@ Build + alle 101 Unit-Tests grün nach beiden Fixes.
 - Restliche Tabs/Bereiche (Übersicht-Diagramm-Interaktion, Sicherungen, Mode-Taste, Settings) wurden
   im Code überflogen, ohne konkreten neuen Fund über die bereits in `found.md`/`HANDOFF.md`
   dokumentierten Punkte hinaus.
+
+---
+
+## 2026-09-17 (Nachtrag 3: README-Milestone-Nachcheck)
+
+Nutzer wies auf den noch offenen Milestone "LAN-Port-Konflikt-Prüfung + 'Fertig'-Button" in
+README.md hin. Beim erneuten Code-Review dieses Bereichs (u.a. wegen des in Runde 1 bereits
+gefixten Race-Bugs #1 in genau dieser Feature) drei weitere, eigenständige Funde derselben
+Bugklasse ("Alert-Dismiss tut nichts") entdeckt und gefixt.
+
+### 10. Drei nicht funktionierende Alert-"Abbrechen"/"OK"-Buttons
+**Status:** fixed (Build + 102 Unit-Tests grün, 1 neuer Regressionstest)
+**Confidence:** hoch (Logikfehler direkt im Code nachvollzogen, nicht live reproduziert)
+
+1. `ReviewApplyView`s "Anwenden fehlgeschlagen"-Alert: OK-Button-Action leer, `isPresented`-
+   Bindings-Setter ebenfalls No-Op — `applyError` wurde nie zurückgesetzt.
+2. `ConnectView`s "Unbekanntes Zertifikat"-Alert: "Abbrechen"-Button-Action komplett leer —
+   `connectionService.state` blieb für immer auf `.needsCertificateConfirmation` hängen, kein Weg
+   zurück außer dem Zertifikat zu vertrauen.
+3. `ConnectView`s "Unbekannter SSH-Schlüssel"-Alert: "Abbrechen" rief nur
+   `dismissPendingSSHTrust()` (löschte nur `pendingSSHTrustFingerprint`) — funktionierte nur für
+   einen von zwei möglichen Auslöse-Pfaden, beim anderen (`state == .needsSSHHostKeyConfirmation`)
+   blieb der Dialog hängen.
+
+**Fix:** neue `ConnectionService.cancelPendingTrustConfirmation()` (setzt `state` bei beiden
+"needs...Confirmation"-Fällen auf `.idle` zurück, löscht zusätzlich `pendingSSHTrustFingerprint`),
+neue `SetupViewModel.dismissApplyError()`. Alle drei Alerts verdrahtet (Button-Action UND
+Bindings-Setter, deckt auch Tap-Outside/Esc-Dismiss ab). Totes `dismissPendingSSHTrust()`
+entfernt.
+
+**Weiterhin offen:** die Port-Konflikt-Prüfung selbst (Warndialoge, "Weiter"-Sperre, "Fertig"-
+Button) ist nach diesem zweiten Code-Review-Durchgang funktional plausibel, aber noch nie
+tatsächlich in der App-UI durchgeklickt worden — dafür bräuchte es einen Live-Test durch den
+Nutzer, da UI-Automatisierung hier nicht verfügbar ist.