feat(host-agent): systemd-Service-Installer + SNI-Doku ueberall

install-service.sh: installiert Binary (/usr/local/bin) + .env (/etc/aria-host-
agent/.env, 0600) + systemd-Unit und macht enable --now. .env-Pfad als Argument
ODER ohne Argument ein ncurses-Dateidialog (dialog --fselect, bietet Installation
von dialog an). Findet die Binary unter dist/ bzw. ./ oder als 2. Argument.

Doku aktualisiert (RVS_SNI fuer RZ-interne Clients + Installer):
- host-agent/README: Installer-Abschnitt + TLS/SNI-Abschnitt.
- README (zentral): Installer + SNI im Host-Agent-Abschnitt (Verweis auf
  Satellit/Compute-Nodes).
- satellite/README + xtts/README: RVS_SNI-Hinweis fuer Boxen/Satelliten im
  RVS-Netz.

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

satellite/README.md

@@ -48,6 +48,11 @@ python satellite.py       # liest .env automatisch
 den Satelliten erreicht). `SATELLITE_LOCATION` ist der Name, über den ARIA das Netz
 anspricht („Büro").
 
+**Satellit im selben Netz wie der RVS** (z.B. Rechenzentrum, direkt auf die
+interne IP statt NAT-Hairpin): `RVS_HOST=<interne-ip>` + **`RVS_SNI=<zert-name>`**
+(der Name, für den das Caddy-Zertifikat gilt). Ohne das scheitert TLS an
+`tlsv1 alert internal error`. Zuhause / normal: `RVS_SNI` leer lassen.
+
 **Kontrolle:** im Log/Diagnostic muss `primary_ip` im Ziel-LAN liegen
 (`192.168.0.x`) — steht da `192.168.65.x` oder `172.x`, sitzt der Satellit im
 falschen (Docker-)Netz.