feat(host-agent): Direktzugriffs-Agent fuer einen Rechner (Phase A: Agent + Build)

Schlanker Agent, der DIREKT auf einem Linux-Rechner laeuft und sich ausgehend
zum RVS verbindet -> ARIA steuert den Rechner auch hinter NAT/Firewall, wo er
sonst nicht erreichbar ist. Anders als der Satellit (LAN-Gateway) steuert der
Agent den Rechner, auf dem er laeuft.

Faehigkeiten (host_command -> host_result): exec (opt. sudo), read, write,
info (CPU/RAM/Disk/Uptime via psutil), screenshot (grim/scrot/maim/import).
sudo-Logik: root -> direkt; SUDO_PASSWORD -> sudo -S; SUDO_NOPASSWD (Live-ISO)
-> sudo -n; sonst klare Fehlermeldung. Gate: CONTROL_ENABLED + RVS-Token.
stdout wird wie beim Satelliten gefenstert (contains/offset/max_chars).

Als portable Onefile-Binary verteilbar (PyInstaller im bullseye-Container fuer
breite glibc-Kompatibilitaet): build.sh + Dockerfile.build. Plus .env.example,
systemd-Unit und README.

Naechste Phasen: RVS ALLOWED_TYPES (host_*), Bridge-Registry + /internal/host*,
Brain-Tools host_list/exec/read/write/info/screenshot.

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

host-agent/README.md

@@ -0,0 +1,62 @@
+# ARIA Host-Agent
+
+Ein schlanker Agent, der **direkt auf einem Rechner** läuft und ARIA erlaubt,
+diesen Rechner zu steuern — auch wenn er sonst aus dem Netz **nicht erreichbar**
+ist (hinter NAT/Firewall, kein offener Port). Der Agent verbindet sich
+**ausgehend** zum RVS (gleicher Token wie der Rest von ARIA).
+
+Unterschied zum **Satelliten**: der Satellit entdeckt und steuert *andere*
+Geräte in einem LAN; der Host-Agent steuert *den Rechner, auf dem er läuft*.
+
+## Fähigkeiten
+
+| Aktion       | Was |
+|--------------|-----|
+| `exec`       | Shell-Kommando ausführen (optional `sudo`), stdout/stderr/exit |
+| `read`       | Datei lesen (Base64, mit Offset/Limit) |
+| `write`      | Datei schreiben/anhängen (Base64 oder Text) |
+| `info`       | OS, CPU/RAM/Disk-Auslastung, Uptime, IP |
+| `screenshot` | Bildschirmfoto (X11: scrot/maim · Wayland: grim) |
+
+ARIA nutzt diese über die Brain-Tools `host_list` / `host_exec` / `host_read` /
+`host_write` / `host_info` / `host_screenshot`.
+
+## Bauen (portable Binary)
+
+```bash
+./build.sh          # braucht Docker; erzeugt dist/aria-host-agent (~15 MB)
+```
+
+Gebaut wird in einem bullseye-Container (altes glibc), damit die Binary auf
+möglichst vielen Distributionen läuft.
+
+## Installieren
+
+1. `dist/aria-host-agent` auf den Ziel-Rechner kopieren.
+2. `.env.example` → `.env` daneben, RVS-Zugang + `CONTROL_ENABLED=true` eintragen.
+3. Starten: `chmod +x aria-host-agent && ./aria-host-agent`
+   — oder als Dienst: siehe `aria-host-agent.service`.
+
+## sudo
+
+Vier Fälle, der Agent wählt automatisch:
+
+1. **Agent läuft als root** (z.B. systemd `User=root`) → volle Rechte, kein sudo nötig.
+2. `SUDO_PASSWORD=…` in der `.env` → `sudo -S` mit Passwort.
+3. `SUDO_NOPASSWD=true` → `sudo -n` (Live-ISO / passwortloses sudo, z.B. Linux
+   Mint vom Stick).
+4. sonst → sudo-Kommandos scheitern mit klarer Meldung.
+
+## Sicherheit
+
+- Reagiert **nur** auf den eigenen RVS-Raum (Token) und **nur**, wenn
+  `CONTROL_ENABLED=true`.
+- Keine offenen Ports (reiner ausgehender Client).
+- Alle Kommandos werden geloggt.
+- Der Agent gibt **vollen** Zugriff auf den Rechner — nur auf Maschinen
+  einsetzen, denen du ARIA anvertraust.
+
+## Hinweis Screenshot
+
+Als Systemdienst fehlt die grafische Session. Für `screenshot` den Agent in der
+Desktop-Session starten (Autostart) oder `DISPLAY`/`XAUTHORITY` in der Unit setzen.