Auto-Update wie beim MSCO Launcher

Beim Start installiert sich ein neuer Launcher sofort selbst (Fortschrittsfenster, Neustart), neue
BSO-Versionen kommen nach dem Anmelden - beides abschaltbar. Einstellungen: Nach Updates suchen /
Installieren und neu starten. Updates wieder nur von der Website; dotnet publish laedt hoch (release.ps1).

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

README.md

@@ -15,8 +15,8 @@ WinForms-Fenster mit WebView2, die Oberfläche (`ui\`) ist in der .exe eingebett
   oder eine neuere Version installiert, bietet es Starten an. `--portable` startet ohne Installation.
 - **BSO-Konto:** Registrieren und Anmelden bei der BSO-Website. Die Anmeldung bleibt 30 Tage (Token DPAPI-verschlüsselt).
   Der Kontoname ist der Name im Spiel.
-- **Auto-Update:** Bei jedem Start fragt der Launcher, ob ein neues Update (Launcher oder Mod) installiert werden soll;
-  dazu neueste Mod-Version vor jedem Spielstart (abschaltbar).
+- **Auto-Update (wie MSCO):** Beim Start installiert sich ein neuer Launcher sofort selbst und startet neu; neue Mod-
+  Versionen kommen beim Start und vor jedem Spielstart (beides abschaltbar). Einstellungen: *Nach Updates suchen*.
   Downloads sind fortsetzbar, SHA-256-geprüft und müssen mit dem **BSO-Release-Schlüssel signiert** sein.
 - **Prüft alles:** Spielordner (alle Steam-Bibliotheken), BSO-Version, .NET 10 Runtime (braucht die Mod).
 - **Freunde & Lobby:** Freunde per Benutzername hinzufügen (online-Anzeige), Lobby erstellen, einladen - SPIELEN des Erstellers startet den Lobby-Server.
@@ -29,13 +29,12 @@ WinForms-Fenster mit WebView2, die Oberfläche (`ui\`) ist in der .exe eingebett
 ## Bauen und veröffentlichen
 
 ```powershell
-dotnet publish -c Release -o publish -p:BsoRelease=true   # bauen + als Gitea-Release veroeffentlichen
-.\release.ps1 -Product launcher -Version 0.3.2 -File publish\BSO-Launcher.exe   # oder von Hand
+dotnet publish -c Release -o publish   # bauen - und die neue Version gleich auf https://bso.mbm.wtf laden
 ```
 
-Updates kommen aus den **Gitea-Releases** auf git.mbm.wtf (Mod: `MrMaho/BSO-Mod`, Launcher: `MrMaho/BSO-Launcher`, beide
-öffentlich). Jedes Release hat die Datei und `bso-release.json` (Version, SHA-256, Signatur). Ist Gitea nicht erreichbar,
-fragt der Launcher die Website; mit `-dev` umgekehrt.
+Wie bei MSCO: `dotnet publish` ruft `release.ps1` auf – signiert die .exe und lädt sie mit Changelog (Abschnitt
+`## <Version>` aus `CHANGELOG.md`) auf die Website. Gibt es die Version schon, passiert nichts; also Version in der
+`.csproj` erhöhen und bauen. `BSO_NO_RELEASE=1` baut nur. Der Launcher holt seine Updates von der Website.
 
 ## Gegen die lokale Test-Website (`-dev`)
 
@@ -53,11 +52,15 @@ Lokale Website starten: im BSO-Website-Repo `dotnet run --urls http://localhost:
 
 ## Release-Schlüssel
 
-`new-release-key.ps1` legt einmalig den Schlüssel an (RSA 3072, privater Teil DPAPI-verschlüsselt unter
-`%APPDATA%\BSO\release-key.dpapi`) und trägt den öffentlichen Teil in `Services\ReleaseSignature.cs` ein.
-`release.ps1` (in BSO-Mod und BSO-Launcher) signiert damit `BSO-RELEASE|produkt|version|sha256` und legt das
-Gitea-Release an – braucht `BSO_GITEA_TOKEN` (Gitea: Einstellungen → Anwendungen → Token mit *repository: Lesen und
-Schreiben*), gern als Windows-Benutzervariable.
+Geheimnisse liegen DPAPI-verschlüsselt unter `%USERPROFILE%\.bso\` (wie `.msco` bei MSCO):
+
+| | Datei | Einrichten |
+|---|---|---|
+| Release-Token (`RELEASE_TOKEN` der Website) | `release-token.dpapi` | `release.ps1 -SaveToken` (oder `BSO_RELEASE_TOKEN`) |
+| Signier-Schlüssel (RSA 3072) | `release-signing-key.dpapi` | `release.ps1 -ImportSigningKey <sicherung>` |
+
+Sicherung: `release.ps1 -ExportSigningKey <datei>` (AES-256, eigenes Passwort). Ein ganz neues Paar nur im Notfall:
+`new-release-key.ps1` (trägt den öffentlichen Teil in `Services\ReleaseSignature.cs` ein).
 
 **Den Schlüssel sichern:** Mit einem neuen Schlüssel erkennen bereits verteilte Launcher keine Updates mehr.