feat(host-agent): Windows-Build aus Docker (Wine) + setup.exe (Dienst)

Dockerfile.win (tobix/pywine): baut die Windows-.exe via Wine+PyInstaller und
per NSIS ein setup.exe, das den Agent via nssm als Autostart-Windows-Dienst
einrichtet und die .env aus %ProgramData%\ARIA-Host-Agent liest (AppDirectory).
build-win.sh als Einstieg; release_agent.sh baut Windows jetzt mit (SKIP_WINDOWS=1
ueberspringt). _load_dotenv haertet: sucht .env auch neben sys.executable (onefile-
.exe-Ort), nicht nur __file__/CWD. README: Windows-Build + Dienst + Release.
macOS bleibt self-build (nicht aus Docker moeglich).

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

host-agent/README.md

@@ -46,11 +46,23 @@ PyInstaller kann **nicht cross-kompilieren** — jede Binary wird auf ihrem OS g
 ./build-native.sh   # -> dist/aria-host-agent
 ```
 
-**Windows** — PyInstaller (Python 3 im PATH nötig):
+**Windows — nativ** (auf einem Windows-Rechner, Python 3 im PATH nötig):
 ```bat
 build-native.bat    REM -> dist\aria-host-agent.exe
 ```
 
+**Windows — aus Docker heraus (auf Linux!), inkl. Installer** — Wine baut die
+`.exe`, NSIS packt ein `setup.exe`, das den Agent als Windows-Dienst einrichtet:
+```bash
+./build-win.sh [version]
+#  -> dist/aria-host-agent.exe        (Konsolen-Binary)
+#  -> dist/aria-host-agent-setup.exe  (Installer: Dienst + .env in ProgramData)
+```
+Der erste Lauf zieht das `tobix/pywine`-Image (~1–2 GB) und richtet die Wine-
+Python-Umgebung ein — das dauert; Folge-Builds sind schnell. PyInstaller kann
+nicht cross-compilen, deshalb der Wine-Umweg. **macOS geht so NICHT** (Apple
+lässt sich nicht legal aus Docker bauen) — dort `./build-native.sh` auf einem Mac.
+
 ### Docker scheitert? (Live-ISO / overlayfs-Root)
 
 Wenn `build.sh` mit `failed to mount … overlayfs … invalid argument` abbricht,
@@ -96,6 +108,36 @@ Danach: `systemctl status aria-host-agent` · `journalctl -u aria-host-agent -f`
 Die Binary sucht er unter `dist/aria-host-agent` bzw. `./aria-host-agent` (oder
 2. Argument). Braucht `dialog` für den Dateibrowser (bietet die Installation an).
 
+### Windows-Dienst (setup.exe)
+
+`aria-host-agent-setup.exe` (aus `build-win.sh` oder dem Gitea-Release) als
+Administrator ausführen. Der Installer:
+- kopiert die `.exe` nach `%ProgramFiles%\ARIA Host-Agent`,
+- legt `%ProgramData%\ARIA-Host-Agent\.env` an (nur falls noch keine da ist),
+- richtet über **nssm** den Dienst **ARIA Host-Agent** ein (Autostart) und startet ihn.
+
+Danach die `.env` unter `%ProgramData%\ARIA-Host-Agent\` mit RVS-Zugang +
+`CONTROL_ENABLED=true` füllen und den Dienst neu starten (`services.msc` →
+*ARIA Host-Agent*, oder `nssm restart ARIAHostAgent`). Deinstallation über
+*Apps & Features* → *ARIA Host-Agent* (die `.env` in ProgramData bleibt erhalten).
+
+## Release (Binaries als Gitea-Assets)
+
+`release_agent.sh <version>` baut alles Docker-Baubare und hängt es als
+**Release-Asset** an den Tag `agent-v<version>` — nichts landet im Git-Tree:
+
+```bash
+./release_agent.sh 0.2.0                 # Linux + Android + Windows (Wine)
+SKIP_WINDOWS=1 ./release_agent.sh 0.2.0  # ohne Windows (schneller)
+```
+
+Assets: `aria-host-agent-linux-x64`, `aria-host-agent-android-agent-v<v>.apk`,
+`aria-host-agent-windows.exe`, `aria-host-agent-windows-setup.exe`. **macOS** ist
+nicht Docker-baubar — auf einem Mac `./build-native.sh` laufen lassen und das
+Ergebnis vor dem Release nach `dist/aria-host-agent-macos` legen, dann nimmt das
+Skript es automatisch mit. Gitea-Zugang via `.env`/Umgebung (`GITEA_URL`,
+`GITEA_REPO`, `GITEA_USER`), Kennwort wird abgefragt.
+
 ## TLS / SNI — Agent im selben Netz wie der RVS
 
 Steht der Rechner im **selben Netz wie der RVS** (z.B. Rechenzentrum) und soll