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>

found.md

@@ -295,3 +295,34 @@ live exploitiert — anders als #5/#6 im vorigen Durchgang):
   hartem Verbindungsabbruch statt einem Vertrauens-Dialog mit unverifizierbarer Kennung.
 
 Build grün, alle 101 Unit-Tests grün. Details in `bugs.md`.
+
+### 14. README-Nachcheck: offener Milestone (Port-Konflikt/"Fertig") + 3 Alert-Dismiss-Bugs
+**Status:** fixed (Build + 102 Unit-Tests grün, Live-Klicktest weiterhin offen)
+
+Nutzer wies auf einen noch offenen Milestone in der README hin (LAN-Port-Konflikt-Prüfung +
+"Fertig"-Button, nie live durchgeklickt). Beim erneuten Code-Review dieses Bereichs (u.a. wegen
+des in dieser Session bereits gefixten Race-Bugs in genau dieser Feature) drei echte,
+eigenständige Bugs derselben Klasse gefunden:
+
+1. `ReviewApplyView`s "Anwenden fehlgeschlagen"-Alert: OK-Button-Action war leer, die
+   `isPresented`-Bindings-Setter-Closure ebenfalls ein No-Op — `applyError` wurde nie
+   zurückgesetzt, der Alert konnte sich nach dem Schließen theoretisch sofort wieder öffnen.
+2. `ConnectView`s "Unbekanntes Zertifikat"-Alert: "Abbrechen"-Button-Action war komplett leer —
+   `connectionService.state` blieb für immer auf `.needsCertificateConfirmation` hängen, es gab
+   keinen 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 dieses Alerts, 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 — sowohl der jeweilige Cancel/OK-Button als auch die Bindings-Setter-Closure (deckt
+auch Tap-Outside/Esc-Dismiss ab). Totes `dismissPendingSSHTrust()` entfernt. Ein neuer
+Regressionstest (`testCancelPendingTrustConfirmationResetsCertificateConfirmationToIdle`).
+
+Build grün, alle 102 Unit-Tests grün. Der ursprünglich gemeldete Milestone (Port-Konflikt-Prüfung
+selbst, inkl. Warndialoge, "Weiter"-Sperre, "Fertig"-Button) bleibt beim Status "Code-Review
+bestätigt" — ein echter Live-Klicktest durch den Nutzer in der App-UI steht weiterhin aus, da
+UI-Automatisierung in dieser Session nicht verfügbar ist.