Fruehjahrsputz: WinForms ausgebaut (P11/L5), LicenseLabrador abgeloest (D-6)

Das Repo enthaelt ab jetzt ausschliesslich plattformneutralen Code. Build gruen
(0 Fehler), 476 Tests gruen, Linux-Publish der Avalonia-App verifiziert.
Rueckfallebene ist der Tag winforms-final, der jetzt auch auf dem Server liegt.

WinForms endgueltig ausgebaut (P11/L5):
- PolyTrader.App.csproj aus PolyTraderSharp.sln genommen und geloescht
- Ui/, Models/, Licensing/, services/, Properties/, Resources/icons/,
  Program.cs, favicon.ico entfernt - rund 4.500 LOC generierter Designer-Code
- Root-appsettings.json entfernt: exaktes Duplikat der Avalonia-Kopie, die die
  App tatsaechlich liest. Zwei Dateien mit gleichem Inhalt laufen frueher oder
  spaeter auseinander.
- Kein net10.0-windows mehr im Repo; Build-Warnungen von 23 auf 15 gesunken
  (die CS0169 aus den Designer-Resten sind weg)

PNG-Symbole gerettet statt geloescht:
Die Avalonia-App band sie per ..\..\Resources\*.png aus dem Repo-Root ein und
haette sie mitverloren. Sie liegen jetzt in src/PolyTrader.App.Avalonia/Assets/,
wo sie hingehoeren. Der avares-Pfad "Assets/<datei>.png" bleibt unveraendert -
in der gebauten Assembly nachgeprueft.

LicenseLabrador abgeloest (D-6):
- LicenseLabrador.Client aus lib/nuget entfernt, Quellen-Mapping in
  NuGet.Config auf Deploymentcenter.* reduziert, lib/nuget/README.md neu
- Bewusste Abweichung vom Plan: die Watchdog*-Felder in ServerSettings bleiben.
  D-1 hat sie auf die Deploymentcenter-API umgewidmet statt sie zu ersetzen;
  sie werden aktiv benutzt. Die Planzeile stammte aus der Zeit davor.

Weitere Altlasten:
- agentspace/ (30 Dateien: WinForms-Designer-Patcher, fix_mongo.py nach der
  MySQL-Migration, tmp/test/scratch-Skripte) entfernt
- Ideen-fuer-Mittwoch.txt entfernt - Inhalt ist laengst umgesetzt
- tote .gitignore-Regel fuer agentspace/antigravity/ entfernt
- lokal entfernt (nicht versioniert): MongoDB/-Exporte, data.db, .bak-Datei

Dokumentation nachgezogen:
- ANALYSE-Linux-Portierung.md auf Revision 6, P11/L5 als erledigt
- LEITFADEN: Abschnitt B vollstaendig aufgeloest, A5 prueft ab jetzt gegen
  einen Worktree des Tags statt gegen den Arbeitsbaum
- UMSETZUNGSPLAN-Watchdog-LicenseLabrador-Integration.md als ABGELOEST
  gekennzeichnet, D-6 im Deploymentcenter-Plan auf den Iststand gezogen

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

lib/nuget/README.md

@@ -1,42 +1,49 @@
 # Lokaler NuGet-Feed (`lib/nuget`)
 
 Hier liegen Pakete aus unseren **eigenen Schwester-Projekten**, die PolyTrader benutzt.
+Aktuell genau eines: `Deploymentcenter.Client` (Lizenz, Watchdog, Fehler-Reporting, Updates).
+
+> Bis zum 22.08.2026 lag hier zusätzlich `LicenseLabrador.Client`. Das Paket ist mit dem
+> Ausbau der WinForms-Anwendung entfernt worden — Lizenzprüfung und Heartbeat laufen
+> vollständig über das Deploymentcenter (siehe
+> `docs/umsetzungsplaene/UMSETZUNGSPLAN-Deploymentcenter-Integration.md`, Schnitt D-6).
+> Der letzte Stand mit LicenseLabrador liegt im Git-Tag `winforms-final`.
 
 ## Warum ein Paket und keine Projektreferenz?
 
-Ursprünglich verwies `PolyTrader.App.csproj` per `ProjectReference` direkt auf
-`..\..\LicenseLabrador\client-dotnet\...`. Das koppelt die Repos hart: PolyTrader
-baut dann nur noch auf einer Maschine, auf der LicenseLabrador zufällig daneben liegt
-— ein Build-Server oder das Zielland-System hätte den Build nicht mehr übersetzen können.
+Eine `ProjectReference` direkt nach `..\..\Deploymentcenter\client-dotnet\...` würde die
+Repos hart koppeln: PolyTrader baute dann nur noch auf einer Maschine, auf der das
+Schwester-Repo zufällig daneben liegt — ein Build-Server oder das Zielland-System hätte
+den Build nicht mehr übersetzen können.
 
 **Die Projekte bleiben eigenständig.** Deshalb wird das SDK als versioniertes
 NuGet-Paket in dieses Verzeichnis gelegt und mitversioniert. Ein reiner DLL-Verweis
-wäre nicht ausreichend gewesen: das Paket trägt die transitiven Abhängigkeiten
-(BouncyCastle.Cryptography, Microsoft.Win32.Registry,
-System.Security.Cryptography.ProtectedData, System.Text.Json) in seinen Metadaten,
-eine nackte DLL nicht.
+wäre nicht ausreichend: das Paket trägt die transitiven Abhängigkeiten in seinen
+Metadaten, eine nackte DLL nicht. Zusätzlich liefert es unter `build/` die
+`Deploymentcenter.BuildInfo.targets` mit, die beim Bauen die Klasse
+`PolyTrader.Core.BuildInfo` (Version, Git-Commit, Build-Datum) erzeugt.
 
-`nuget.config` bindet dieses Verzeichnis als Quelle `local` ein. Das
-`packageSourceMapping` löst `LicenseLabrador.*` **ausschließlich** lokal auf, damit
+`NuGet.Config` bindet dieses Verzeichnis als Quelle `local` ein. Das
+`packageSourceMapping` löst `Deploymentcenter.*` **ausschließlich** lokal auf, damit
 ein gleichnamiges Paket auf nuget.org unsere Version nicht verdrängen kann
 (Dependency Confusion).
 
 ## Neue SDK-Version übernehmen
 
-1. Im LicenseLabrador-Repo die `<Version>` in
-   `client-dotnet/LicenseLabrador.Client/LicenseLabrador.Client.csproj` **anheben**
+1. Im Deploymentcenter-Repo die `<Version>` in
+   `client-dotnet/Deploymentcenter.Client/Deploymentcenter.Client.csproj` **anheben**
    (gleiche Version zweimal zu packen führt zu stillen Cache-Treffern — NuGet
    unterscheidet Pakete nur an der Versionsnummer).
 2. Paket bauen:
 
    ```
-   dotnet pack J:\Softwareprojekte\LicenseLabrador\client-dotnet\LicenseLabrador.Client\LicenseLabrador.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget
+   dotnet pack J:\Softwareprojekte\Deploymentcenter\client-dotnet\Deploymentcenter.Client\Deploymentcenter.Client.csproj -c Release -o J:\Softwareprojekte\PolytraderSharp\PolyTraderSharp\lib\nuget
    ```
 
-3. In `PolyTrader.App.csproj` die `Version` der `PackageReference` auf die neue
-   Nummer setzen.
+3. In `src/PolyTrader.Core/PolyTrader.Core.csproj` die `Version` der `PackageReference`
+   auf die neue Nummer setzen.
 4. Die alte `.nupkg` löschen, damit klar bleibt, welche Fassung gilt.
 5. `dotnet build` + `dotnet test` — und die neue `.nupkg` mit committen.
 
-**Wichtig:** Die Änderung am SDK gehört zuerst ins LicenseLabrador-Repo und wird dort
+**Wichtig:** Die Änderung am SDK gehört zuerst ins Deploymentcenter-Repo und wird dort
 committet. Dieses Verzeichnis ist nur die Auslieferung, nicht der Arbeitsort.