feat: lokaler MCP-Server, Phase 4 (Elternbrief-Vorlagen + Claude-Desktop-Registrierung)

Schließt die MCP-Server-Spec ab. "Worksheets" aus der Spec entsprechen
im tatsächlichen Datenmodell den .lavorlage-Elternbrief-Vorlagen
(LehrerApp.Templating) - es gibt kein separates Arbeitsblatt-Konzept mit
Fach/Klassenstufe-Metadaten. Neue Tools list_letter_templates (Read) und
render_letter (Read, liefert Base64-PDF, kein DB-Schreibzugriff).

upload_worksheet/update_worksheet bewusst nicht umgesetzt: das
Seitenlayout ist eine eigene positionsbasierte DSL mit eigenem
visuellen Editor (LehrerApp.TemplateDesigner) - ein LLM müsste sie
blind erzeugen, mit hohem Risiko für kaputte Layouts. Platzhalter-Logik
aus CreateLetterDialogViewModel nach LetterPlaceholderBuilder extrahiert,
damit Dialog und MCP-Tool nicht auseinanderdriften.

Neuer McpClientRegistrationService trägt den Bridge-Pfad in Claude
Desktops claude_desktop_config.json ein (Button in den Einstellungen,
nie automatisch), ohne bestehende Fremdeinträge zu verlieren und ohne
eine nicht lesbare Konfigurationsdatei zu überschreiben.

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

TODO.md

@@ -2589,6 +2589,53 @@ folgenden Punkte gehören direkt in `LehrerApp.Desktop`:
         vertrauen, dass `update_lesson`/`update_lesson_phase` wirklich nur die angegebenen Felder
         ändern, und dass ein zu großer Anhang beim Download einen Fehler statt einer Antwort liefert.
 
+- [x] **4.5.29** Lokaler MCP-Server, Phase 4 (Elternbrief-Vorlagen + Claude-Desktop-Registrierung),
+      2026-09-11 — schließt die Spec ab (Rest siehe "Bewusst nicht umgesetzt" unten).
+      - **"Worksheets" umbenannt zu Elternbrief-Vorlagen:** die Spec sah `list_worksheets`/
+        `download_worksheet`/`upload_worksheet`/`update_worksheet` mit Fach-/Klassenstufe-Metadaten
+        vor — das existiert im Datenmodell nicht. Was tatsächlich existiert, ist der
+        `.lavorlage`-Vorlagenmechanismus (`LehrerApp.Templating`), der ausschließlich für
+        Elternbriefe genutzt wird (an Schüler+Kontakt gebunden, siehe
+        `CreateLetterDialogViewModel`). Neue Tools `list_letter_templates` (Read) und
+        `render_letter` (Read — schreibt nichts in die Datenbank, deshalb ohne Bestätigungsdialog,
+        liefert ein Base64-PDF).
+      - **`upload_worksheet`/`update_worksheet` bewusst NICHT umgesetzt:** das Seitenlayout ist
+        eine eigene, positionsbasierte DSL (`LayoutParser`/`.tpl`-Dateien mit absoluten
+        Koordinaten), für die es einen eigenen visuellen Editor gibt (`LehrerApp.TemplateDesigner`)
+        — ein LLM müsste diese DSL blind erzeugen, mit hohem Risiko für unbrauchbare oder defekte
+        Layouts. `render_letter` deckt den tatsächlich nützlichen Fall ab: eine bestehende,
+        von Hand gestaltete Vorlage mit Werten füllen.
+      - **Platzhalter-Logik aus `CreateLetterDialogViewModel` extrahiert** nach
+        [Services/LetterPlaceholderBuilder.cs](LehrerApp.Desktop/Services/LetterPlaceholderBuilder.cs),
+        damit Dialog und MCP-Tool exakt dieselben Standard-Platzhalternamen (Datum, Anrede,
+        Contact.Address, ...) befüllen, statt still auseinanderzudriften. Bestehende
+        `CreateLetterDialogViewModelTests` liefen nach dem Refactor unverändert grün.
+      - **Registrierungs-Workflow:** neuer
+        [McpClientRegistrationService.cs](LehrerApp.Desktop/Services/Mcp/McpClientRegistrationService.cs)
+        trägt den Bridge-Pfad in `claude_desktop_config.json` ein (Windows: `%APPDATA%\Claude\...`,
+        macOS: `~/Library/Application Support/Claude/...`) — bewusst nur für Claude Desktop, der
+        einzige in der Spec konkret genannte Client mit dokumentierter Config-Konvention. Button
+        "Bei Claude Desktop eintragen"/"Eintrag entfernen" im MCP-Einstellungen-Tab, bewusst nur
+        auf explizite Nutzeraktion, nie automatisch beim App-Start (Schreiben in die
+        Konfigurationsdatei eines fremden Programms ist ein sichtbarer externer Seiteneffekt).
+        Bestehende Config-Inhalte (andere MCP-Server, sonstige Claude-Desktop-Einstellungen)
+        bleiben beim Eintragen erhalten; eine nicht als JSON lesbare bestehende Datei wird nicht
+        angefasst, sondern liefert einen Fehler mit Pfadangabe statt sie zu überschreiben.
+        Funktioniert nur bei einer gepackten Installation (Bridge liegt neben der
+        Hauptapp-Executable) — bei einem lokalen `dotnet build/run` liegt die Bridge in ihrem
+        eigenen separaten bin-Ordner und wird nicht gefunden.
+      - `McpToolScope`/`McpServerHostedService` um `list_letter_templates`/`render_letter`
+        erweitert (9 Read-, 10 Write-Tools). 6 neue Tests in
+        [LetterTemplateToolsTests.cs](LehrerApp.Desktop.Tests/LetterTemplateToolsTests.cs)
+        (rendert echte PDFs über `QuestTemplateRenderer`, kein Fake) und 6 in
+        [McpClientRegistrationServiceTests.cs](LehrerApp.Desktop.Tests/McpClientRegistrationServiceTests.cs)
+        (u.a. bestehende Fremdeinträge bleiben erhalten, kaputtes JSON wird nicht überschrieben).
+      - **Bewusst nicht umgesetzt (verworfen, nicht nur zurückgestellt):** `upload_worksheet`/
+        `update_worksheet` (siehe oben), Mehrbenutzer-/Remote-Zugriff, Lösch-Tools,
+        Dokumentationstypen-Zugriff, Zugriff über den Sync-Server — alle laut Spec explizit
+        "Out of Scope (v1)". Windows-Installer-Anpassungen und die Runtime-Dedup-Optimierung für
+        macOS (4.5.27) bleiben offen, sind aber nicht MCP-spezifisch.
+
 **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`,