feat: lokaler MCP-Server, Phase 1 (Infrastruktur + Read-Tools)

Erlaubt einem lokalen KI-Client (z.B. Claude Desktop) strukturierten
Lesezugriff auf Schüler, Klausuren, Noten, Stundenplan und Zeiterfassung.
Neuer LehrerApp.McpBridge-Prozess reicht stdio-JSON-RPC über eine Named
Pipe an einen In-Process-MCP-Server im Avalonia-Hauptprozess durch
(ModelContextProtocol.Core, StreamServerTransport direkt auf der Pipe).
Standardmäßig deaktiviert, Opt-in über neuen Einstellungen-Tab.
Dokumentationstypen (Gesprächsnotizen/Vorfälle/Förderpläne) sind auf
Code-Ebene nie erreichbar (McpToolScope, analog PlainEventStore.Allowed).

Write-Tools, Bestätigungsdialog-UI, Worksheets/Lesson-Plans-Tools und
macOS-Packaging folgen in späteren Phasen (siehe TODO.md 4.5.25).

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

TODO.md

@@ -2461,6 +2461,45 @@ folgenden Punkte gehören direkt in `LehrerApp.Desktop`:
         `WeekCellItem.Date` — letzteres ist nur bei Kopfzeilen gesetzt, nicht bei
         Stunden-Kacheln (führte im ersten Testlauf zu einem Bug: die Automatik griff nie).
 
+- [x] **4.5.25** Lokaler MCP-Server, Phase 1 (Infrastruktur + Read-Tools), 2026-09-11: erlaubt einem
+      lokalen KI-Client (z.B. Claude Desktop) strukturierten Lesezugriff auf Schüler, Klausuren,
+      Noten, Stundenplan und Zeiterfassung — analog zur bestehenden Regel "LLM nur für Intent, nie
+      für Geometrie" gilt hier "LLM nur für Anfrage/Absicht, nie für direkten Datenbankzugriff":
+      alle Zugriffe laufen über typisierte Tools, kein freier Query-Zugriff.
+      - **Architektur:** neues, eigenständiges `LehrerApp.McpBridge`-Projekt (Konsolenprozess, vom
+        KI-Client per stdio gestartet) reicht JSON-RPC-Nachrichten zeilenweise unverändert über
+        eine Named Pipe (`LehrerApp.Core/Mcp/McpPipeConstants.cs`) an einen In-Process-MCP-Server im
+        laufenden Avalonia-Hauptprozess durch
+        ([McpServerHostedService.cs](LehrerApp.Desktop/Services/Mcp/McpServerHostedService.cs)).
+        Grund: LiteDB ist Single-Writer/Embedded ohne Cross-Prozess-Benachrichtigung — ein
+        separater Prozess mit eigener DB-Verbindung hätte Stale-Reads gegenüber der laufenden GUI
+        riskiert. Nutzt `ModelContextProtocol.Core` (`StreamServerTransport` direkt auf dem
+        `NamedPipeServerStream`, kein eigenes JSON-RPC-Parsing nötig) statt eines
+        selbstgebauten Protokolls.
+      - **Tools (5, alle Read-only):** `get_students`, `get_exams`, `get_grades`, `get_schedule`,
+        `get_time_entries` — je eine schlanke Tool-Klasse unter
+        [Services/Mcp/Tools/](LehrerApp.Desktop/Services/Mcp/Tools/), DTOs statt direkt
+        serialisierter LiteDB-Entities. `McpToolScope.cs` dokumentiert die Allowlist der
+        exponierten Tool-Namen nach demselben Muster wie `PlainEventStore.Allowed` (Klartext-
+        Sync-Kanal) — Gesprächsnotizen/Vorfälle/Förderpläne (`Documentation`/`Vorgang`) werden von
+        keiner Tool-Klasse referenziert und sind damit technisch nie erreichbar, nicht nur per
+        Konvention.
+      - **Opt-in:** standardmäßig deaktiviert, `McpSettingsService` + Checkbox im neuen
+        Einstellungen-Tab "MCP-Server" (`SettingsViewModel.McpSettings.cs`). Kein Token/Login nötig
+        (anders als bei 4.5.9) — die Named Pipe selbst ist die Vertrauensgrenze (lokaler Prozess,
+        gleiche Windows-Session bzw. Unix-Dateirechte). Wirkt erst nach Neustart der App (kein
+        Live-Reload des Pipe-Listeners).
+      - **Verifiziert:** End-to-End-Smoke-Test (Bridge-Prozess als echter Kindprozess, `initialize`
+        → `tools/list` → `tools/call get_students` über die reale Named Pipe) bestätigt die volle
+        Kette; 9 Unit-Tests für Tool-Filterlogik und die Scope-Allowlist in
+        [McpToolsTests.cs](LehrerApp.Desktop.Tests/McpToolsTests.cs).
+      - **Bewusst zurückgestellt (spätere Phasen):** Write-Tools samt Bestätigungsdialog-UI,
+        `get_lesson_plans`, Worksheets-Tools (`list_worksheets`/`download_worksheet`/...),
+        macOS-Bundle-Signierung der Bridge-Binary, Named-Pipe-basierte
+        Einzelinstanz-Absicherung (die Spec-Idee dazu funktioniert nicht, da die Pipe nur bei
+        aktiviertem Opt-in existiert — LehrerApp hat ohnehin noch keinen
+        Single-Instance-Mechanismus, unabhängig von MCP).
+
 **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`,