fix: Geräte-Pairing - Fehlschlag beim Einlösen war unsichtbar

RedeemPairingCode() rief nach einem Fehlschlag sofort RestartApplication()
auf, direkt nach dem Setzen von PairingStatus - die Fehlermeldung konnte
nie gerendert werden, und wurde auch nirgends geloggt. Ein Fehlschlag
(falscher/abgelaufener Code, Server nicht erreichbar) wirkte dadurch wie
ein kommentarloser Absturz ohne jede Spur.

- SettingsViewModel loggt den Fehler jetzt über AppLogger und zeigt vor
  dem Neustart einen Bestätigungsdialog mit der echten Fehlermeldung an.
- AppBootstrapper.RestartApplication() gibt unter dotnet run/IDE-Debug
  (wo ProcessPath auf den dotnet-Host statt die App zeigt) die
  ursprünglichen Kommandozeilenargumente beim Neustart mit, statt nur
  die dotnet-CLI-Hilfe zu öffnen.

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

LehrerApp.Desktop/AppBootstrapper.cs

@@ -82,7 +82,17 @@ public static class AppBootstrapper
     {
         var exePath = Environment.ProcessPath;
         if (!string.IsNullOrEmpty(exePath))
-            System.Diagnostics.Process.Start(exePath);
+        {
+            var psi = new System.Diagnostics.ProcessStartInfo(exePath) { UseShellExecute = false };
+            // Unter "dotnet run"/IDE-Debug zeigt ProcessPath auf den SDK-Host (dotnet[.exe]) statt
+            // auf die App selbst - ein Neustart ohne Argumente würde nur die dotnet-CLI-Hilfe
+            // anzeigen statt die App neu zu starten. Die ursprünglichen Kommandozeilenargumente
+            // (u.a. der DLL-Pfad) erneut mitgeben deckt auch diesen Fall ab.
+            if (Path.GetFileNameWithoutExtension(exePath).Equals("dotnet", StringComparison.OrdinalIgnoreCase))
+                foreach (var arg in Environment.GetCommandLineArgs())
+                    psi.ArgumentList.Add(arg);
+            System.Diagnostics.Process.Start(psi);
+        }
         Environment.Exit(0);
     }