Fruehjahrsputz: WinForms-Altlast entfernt, Dokumentation nachgezogen

Die Avalonia-Portierung ist abgeschlossen, damit ist die in ClawdDotNet.slnx
angekuendigte Aufgabe "WinForms-Oberflaeche entfernen" faellig. Der Stand
davor liegt unter dem Tag vor-fruehjahrsputz-2026-08.

Entfernt (56 Dateien, seit dem Herausloesen der Anwendungsschicht nicht mehr
Teil des Builds): ClawdDotNet.csproj, Program.cs, sieben frm_*-Formulare,
UI/, Models/, EmbeddedUI/, Properties/, Resources/, Services/, das alte
Anwendungssymbol und Deploy-Build.ps1 (ersetzt durch deploy/publish.py).
Dazu configs/*.json - Beispielkonfigurationen aus der Zeit vor dem
Instanzverzeichnis, auf die nur noch die alten Prompts verwiesen.

Die vier Entwicklungs-Prompts der Anfangszeit ziehen nach docs/archiv/ um,
mit README, das ihren Stand einordnet. Eine Regel darin gilt weiter - die
Pflichtfelder fetchedAt/dataAsOf/source der Internet-Tools -, deshalb
Archiv statt Loeschen; der WebSearch-Plan verweist auf den neuen Pfad.

Toter Code
- PlaceholderPageViewModel samt Ansicht: Es gibt keinen Platzhalter-Bereich
  mehr, seit alle neun Seiten portiert sind.
- Snappier als direkter Paketverweis: MongoDB.Driver loest es ohnehin auf
  dieselbe Fassung auf, der Verweis hob nichts an.

Zwei Fehler, die dabei sichtbar wurden
- Die taegliche Sicherung lief ins Leere. Die Oberflaeche bot sie an und
  schrieb Uhrzeit, Zielordner und Anzahl in die Einstellungen, aber der
  BackupScheduler wurde nirgends erzeugt. Jetzt am AppHost verdrahtet und
  in den geordneten Abbau aufgenommen.
- SettingsPageViewModel hielt die vier Sicherungs-Einstellungen doppelt.
  Aus der Ansicht waren sie laengst verschwunden, gelesen und beim
  Speichern zurueckgeschrieben wurden sie weiter: Wer die Uhrzeit auf der
  Sicherungs-Seite aenderte und danach die Einstellungen speicherte, bekam
  den alten Wert zurueck.

Pakete: keine bekannten Sicherheitsluecken mehr
- SQLitePCLRaw.bundle_e_sqlite3 auf 2.1.13 angehoben. Microsoft.Data.Sqlite
  bringt 2.1.11 mit, darin steckt GHSA-2m69-gcr7-jv3q (NU1903, hoch).
- SharpCompress bleibt als direkter Verweis stehen. Beim Aufraeumen erst
  als ungenutzt entfernt - dabei kam die von MongoDB.Driver gezogene
  Fassung 0.30.1 mit GHSA-6c8g-7p36-r338 zurueck. Der Verweis ist eine
  Anhebung, kein Ballast; das steht jetzt als Kommentar dabei.

Dokumentation
- Roadmap mit Statusblock: A1 und A3 erledigt, A2 nur zur Haelfte - Gate,
  Policy und Dienst greifen, aber keine Ansicht ruft ApproveAsync auf, ein
  gestagter Aufruf liegt unbeantwortet. Das ist jetzt Punkt 1 der Reihung.
  Rocket.Chat steht und kollidiert mit A5 (Matrix) - Entscheidung faellig.
- Avalonia-Portierungsleitfaden -> Oberflaechen-Leitfaden: kein Auftrag mehr,
  sondern Beschreibung des Stands.
- Bestandsaufnahme und Linux-Analyse als datierte Befunde gekennzeichnet;
  der teure Teil der Linux-Analyse (8.900 Zeilen WinForms) ist hinfaellig.
- Verweise auf frm_*, WebView2 und ClawdDotNet.csproj in den lebenden
  Dokumenten richtiggestellt.

Build fehlerfrei, 585 Tests gruen (6 uebersprungen).

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

docs/RocketChat-Nextcloud-Konzept.md

@@ -6,7 +6,14 @@ Der typische Ablauf ist die Kombination aus beidem — „schreib mir die Auswer
 sie in die Cloud" im Chat, Datei in Nextcloud, Link zurück in den Chat.
 
 Dieses Dokument prüft die Machbarkeit, legt den Schnitt fest und benennt die Punkte, die
-vor der Umsetzung entschieden werden müssen. **Es ist noch keine Umsetzungsfreigabe.**
+vor der Umsetzung entschieden werden müssen.
+
+> **Stand 2026-08-23:** Der Rocket.Chat-Teil ist **umgesetzt** —
+> `src/ClawdDotNet.Tools.RocketChat`, im `AppHost` registriert, `send_file`
+> freigabepflichtig. Der Befund unten bleibt als Begründung stehen; Abschnitt 2.0
+> hält fest, was die Messung gegen die echte Instanz an den Annahmen korrigiert hat.
+> **Offen:** der Nextcloud-Teil und die Kollision mit Roadmap A5 (Matrix) — die ist
+> eine Entscheidung, keine Umsetzung.
 
 Verwandt: [Taskboard-Konzept](Taskboard-Konzept.md) (Scanner/Wake), [Staging-Konzept](Staging-Konzept.md)
 (Freigaben), [Audit-Konzept](Audit-Konzept.md), [Roadmap](Roadmap.md) (A5 — siehe Konflikt unten).
@@ -177,7 +184,7 @@ der richtige Ansatz und wird von Rocket.Chat direkt unterstützt.
 - Authentifiziert wird jeder Aufruf über zwei Header: `X-Auth-Token` und `X-User-Id`.
 
 **Entscheidung, die ich empfehle:** Das Anlegen der Benutzer ist **kein Agenten-Tool**.
-Es ist eine einmalige Einrichtungsfunktion in der WinForms-Oberfläche
+Es ist eine einmalige Einrichtungsfunktion in der Oberfläche
 (Instanz-Einstellungen → Rocket.Chat → „Agenten-Benutzer anlegen"). Sonst müsste ein
 Agent ein Admin-Token halten — und ein Admin-Token in Reichweite einer Prompt-Injection
 ist genau das, was A2 verhindern soll. Der Admin-Token liegt in der **Instanz**-Konfiguration,
@@ -444,7 +451,7 @@ Das ist die Anforderung, die die Architektur bestimmt — nicht der Chat selbst.
 
 | Kanal | Unabhängig von Rocket.Chat? | Richtung |
 |---|---|---|
-| WinForms-Chat (`frm_chat`) | vollständig — läuft in der App selbst | beide |
+| Chat-Seite in der App (`ChatPageView`) | vollständig — läuft in der App selbst | beide |
 | Telegram-Bot-Tool | ja — fremde Infrastruktur | beide |
 | Mail-Tool | ja, sofern der Mailserver anderswo läuft | beide |
 | Web-Chat / `ClawdDotNetApi` | ja, aber nur im lokalen Netz | beide |
@@ -483,7 +490,7 @@ Ein Tool-Job `rocketchat_health` (Takt ~5 Minuten, `GET /api/info`):
 
 **Eingehend während des Ausfalls:** Der Telegram-Poll-Job bleibt dauerhaft aktiv, nur mit
 langsamem Takt (z. B. alle 5 Minuten). Er kostet nichts, wenn nichts kommt — und ist im
-Ernstfall der Weg, auf dem *du* die Agenten erreichst. Der WinForms-Chat ist ohnehin immer
+Ernstfall der Weg, auf dem *du* die Agenten erreichst. Die eingebaute Chat-Seite ist ohnehin immer
 da, solange die App läuft.
 
 **Entschieden (August 2026): Telegram ist der Notfallkanal.** Die Kanalliste lautet damit
@@ -706,9 +713,9 @@ Damit der Zuschnitt klar ist:
 
 - Keine Rocket.Chat-**App** (Apps-Engine, TypeScript im Server) — wir bleiben Client.
 - Keine Verwaltung von Rocket.Chat durch Agenten (Benutzer anlegen, Räume erstellen,
-  Rechte vergeben). Das ist Admin-Arbeit in der WinForms-Oberfläche.
+  Rechte vergeben). Das ist Admin-Arbeit in der Oberfläche.
 - Keine Sprach-/Videofunktionen, keine Nextcloud Talk-Anbindung.
-- Kein Ersatz für den WinForms-Chat — der bleibt und ist die unterste Rückfallebene.
+- Kein Ersatz für die eingebaute Chat-Seite — die bleibt und ist die unterste Rückfallebene.
 - Keine Ende-zu-Ende-Verschlüsselung. Rocket.Chat kann das, aber verschlüsselte Räume sind
   über die REST-API nicht lesbar. Agenten arbeiten in unverschlüsselten Räumen — das ist
   eine bewusste Einschränkung, die du kennen solltest.