fix(satellite): Selbstdiagnose fuers Netz — warnt bei Docker-/NAT-Netz

Symptom: Satellit fand nur Docker-Container (192.168.65.x / 172.18.x) statt der
echten LAN-Geraete. Ursache ist kein Bug, sondern das Deployment-Netz: auf Docker
Desktop (Mac/Windows) ist network_mode:host das Docker-VM-NAT, nicht das echte LAN
— mDNS/SSDP erreichen die realen Geraete nicht.

- satellite.py: _net_context() ermittelt primary_ip + alle IPs und WARNT, wenn der
  Satellit in einem Docker-/NAT-Netz laeuft (192.168.65.x oder 172.16-31.x). Netz-
  Info wird in sat_hello + sat_devices mitgeschickt und beim Start geloggt.
- Diagnostic: zeigt Netz (primary_ip) pro Satellit + eine rote ⚠-Box mit der
  Warnung, wenn er im falschen Netz sitzt.
- README/compose: klar dokumentiert, dass der Satellit im ECHTEN Ziel-LAN laufen
  muss (Linux Docker Engine ODER nativ python satellite.py); Docker-Desktop-Falle.

py/node clean.

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

satellite/README.md

@@ -10,21 +10,44 @@ Ferienwohnung …). Er verbindet sich als RVS-Client in Stefans Raum und gibt AR
 - **Hände (Steuerung):** **DIAL-App-Launch** (z.B. YouTube-Video auf dem Fire TV),
   **Wake-on-LAN**, generisches **HTTP**. Nur wenn freigeschaltet (siehe Sicherheit).
 
-## Deploy
+## ⚠️ Wichtig: der Satellit MUSS im echten Ziel-LAN laufen
 
+Discovery (mDNS/SSDP-Multicast + ARP) funktioniert **nur**, wenn der Prozess
+tatsächlich im selben LAN wie die Geräte hängt — z.B. `192.168.177.0/24`, wo der
+Fire TV steht.
+
+**Docker Desktop (Mac/Windows) geht NICHT.** Dort ist `network_mode: host` das Netz
+der Docker-Linux-VM (NAT, `192.168.65.x` / `172.x`), **nicht** dein echtes LAN.
+Der Satellit sieht dann nur Docker-Container statt der echten Geräte. (Der Satellit
+erkennt das selbst und meldet eine ⚠-Warnung im Diagnostic + Log.)
+
+Richtig deployen — zwei Wege:
+
+**A) Linux-Box im Ziel-LAN mit Docker Engine** (empfohlen, z.B. Raspberry Pi / NUC im Büro):
 ```bash
 cd satellite
-cp .env.example .env      # RVS-Zugang + SATELLITE_LOCATION eintragen
+cp .env.example .env            # RVS-Zugang + SATELLITE_LOCATION
 docker compose up -d --build
-docker compose logs -f    # "sat_hello gesendet" + "[scan] N Geraete"
+docker compose logs -f          # "Netz: primary_ip=192.168.177.x" + "[scan] N Geraete"
+```
+`network_mode: host` (schon gesetzt) gibt hier echtes LAN + Multicast.
+
+**B) Nativ als Python-Prozess** (für Mac/Windows-Test oder ohne Docker) — läuft direkt
+auf einer Maschine im Ziel-LAN:
+```bash
+cd satellite
+pip install -r requirements.txt
+export RVS_HOST=... RVS_TOKEN=... SATELLITE_LOCATION="Wohnung" CONTROL_ENABLED=true
+python satellite.py
 ```
 
 `RVS_HOST/PORT/TLS/TOKEN` **identisch** zum Haupt-Stack (gleicher Raum, damit ARIA
 den Satelliten erreicht). `SATELLITE_LOCATION` ist der Name, über den ARIA das Netz
 anspricht („Büro").
 
-> **`network_mode: host` ist Pflicht** (schon in der compose gesetzt): nur so sieht
-> der Container die mDNS/SSDP-Broadcasts und die Geräte-IPs des LAN.
+**Kontrolle:** im Log/Diagnostic muss `primary_ip` im Ziel-LAN liegen
+(`192.168.177.x`) — steht da `192.168.65.x` oder `172.x`, sitzt der Satellit im
+falschen (Docker-)Netz.
 
 ## So nutzt ARIA es