feat: prominenterer Bestätigungsdialog + move_lesson/delete_lesson (Nutzer-Feedback)

Nach dem ersten Live-Test mit echtem Bridge-Prozess: der bisherige
ConfirmDialog fiel zu wenig auf, wenn LehrerApp im Hintergrund lief
(Normalfall, da der Anstoß vom KI-Client in einem anderen Fenster
kommt). Neuer, eigenständiger McpConfirmDialog statt Änderung am
geteilten ConfirmDialog (hätte alle anderen Aufrufer mitbetroffen):
breiter, auffälliger Kopfbereich, Topmost. AvaloniaMcpConfirmationService
holt das Hauptfenster zusätzlich aus einer möglichen Minimierung und
aktiviert es vor dem Anzeigen.

move_lesson kapselt die bereits vorhandene LessonSchedulingService.Move
(shiftFollowingLessons öffnet eine Lücke für eine neue Stunde, indem
spätere Stunden derselben Einheit mitverschoben werden) - keine neue
Terminlogik, nur Wiederverwendung.

delete_lesson ist eine bewusste, gezielte Ausnahme von "v1 ohne
Lösch-Tools" auf expliziten Nutzerwunsch: eigene
AllowedDestructiveWriteTools-Liste, Destructive=true-Annotation,
Bestätigungstext betont ausdrücklich die fehlende Papierkorb-Deckung
für Lessons.

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

TODO.md

@@ -2650,6 +2650,40 @@ folgenden Punkte gehören direkt in `LehrerApp.Desktop`:
       ohne erneutes `get_lesson_plans` möglich ist. 4 neue Tests in
       [McpToolsTests.cs](LehrerApp.Desktop.Tests/McpToolsTests.cs) (jetzt 32).
 
+- [x] **4.5.31** Bestätigungsdialog-Prominenz + `move_lesson`/`delete_lesson` (2026-09-12,
+      Nutzer-Feedback nach erstem Live-Test mit echtem Bridge-Prozess).
+      - **Dialog fiel zu wenig auf:** der bisher wiederverwendete `ConfirmDialog` (Views/Shared,
+        an vielen anderen Stellen der App für Routine-Bestätigungen im Einsatz) ist nur zum
+        Hauptfenster modal — läuft LehrerApp im Hintergrund, während der Anstoß von einem
+        KI-Client in einem anderen Fenster kommt (der Normalfall bei MCP), geht der Dialog leicht
+        unter. Neuer, eigenständiger
+        [McpConfirmDialog](LehrerApp.Desktop/Views/Mcp/McpConfirmDialog.axaml) statt einer
+        Style-Änderung am geteilten `ConfirmDialog` (hätte alle dessen bestehenden Aufrufer
+        mitbetroffen): breiter (520 statt 420), auffälliger Kopfbereich ("Vorschlag deines
+        KI-Assistenten — bitte prüfen"), `Topmost`. `AvaloniaMcpConfirmationService` holt das
+        Hauptfenster zusätzlich aus einer möglichen Minimierung und aktiviert es
+        (`WindowState`/`Activate()`), bevor der Dialog erscheint.
+      - **`move_lesson`:** deckt sowohl "eine Stunde verschieben" als auch "Lücke für eine neue
+        Stunde öffnen" ab, indem es die bereits vorhandene, bislang nur UI-seitig genutzte
+        [LessonSchedulingService.Move](LehrerApp.Core/Services/LessonSchedulingService.cs) kapselt
+        (`shiftFollowingLessons=true` verschiebt alle späteren, noch nicht durchgeführten Stunden
+        derselben Einheit um denselben Tages-Versatz mit — "Lücke öffnen" = die Stunde hinter der
+        Lücke so verschieben, danach `create_lesson` auf das freigewordene Datum). Keine neue
+        Terminlogik geschrieben, nur wiederverwendet.
+      - **`delete_lesson` — bewusste, gezielte Ausnahme von "v1 ohne Lösch-Tools":** explizite
+        Nutzeranforderung. `Lesson` hängt (anders als die meisten anderen Entitäten) nicht am
+        Papierkorb-System — `ILessonRepository.Delete` löscht endgültig, kein `Restore`. Deshalb:
+        eigene `McpToolScope.AllowedDestructiveWriteTools`-Liste getrennt von den normalen
+        Write-Tools (fällt beim Lesen sofort auf), `Destructive = true`-Annotation im
+        MCP-Protokoll, und eine Bestätigungsnachricht, die explizit "NICHT rückgängig zu machen"
+        sagt (Wortlaut an den bestehenden Lösch-Dialog in `PlanningTabView.axaml.cs`
+        angelehnt: "wird endgültig gelöscht").
+      - 8 neue Tests in [McpToolsTests.cs](LehrerApp.Desktop.Tests/McpToolsTests.cs) (jetzt 40),
+        u.a.: `shiftFollowingLessons` verschiebt nur Stunden NACH der bewegten, nicht davor;
+        ein belegtes Ziel liefert nach bereits erfolgter Bestätigung einen Fehler statt
+        stillschweigend zu überschreiben (die bestehende `EnsureTargetIsFree`-Prüfung in
+        `LessonSchedulingService` greift unverändert).
+
 **Wichtige Abweichung von der ursprünglichen Planung (5.2):** Vor der Umsetzung zeigte sich,
 dass 5.2 wie ursprünglich beschrieben eine zweite, parallele Fehlzeiten-Erfassung neben dem
 bereits bestehenden Anwesenheits-Tracking aus Kapitel 3 (`ParticipationEntry.Attendance`,