Spec richtiggestellt: Gaeste werden ueber den Proxmox-Gastagenten gelesen, nicht ueber SSH

Ich hatte 'ueber den bestehenden SSH-Weg' geschrieben. Das stimmt fuer Hosts und
ist fuer Kundeninstanzen falsch: jeder Befehl im Gast laeuft im Produkt ueber
guestExec, also den QEMU-Gastagenten via Proxmox-API — so macht es jeder
occ-Aufruf. Falsch beschrieben haette der Plan den Melder auf einen Weg gebaut,
den es fuer Gaeste gar nicht gibt.

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

docs/superpowers/specs/2026-08-03-fruehwarnsystem-design.md

@@ -41,7 +41,10 @@ Nextcloud an. Sie sehen von alldem nichts.
 
 ## 1. Erkennen
 
-Zwei Quellen, beide nur **gelesen**, beide über den bestehenden SSH-Weg.
+Zwei Quellen, beide nur **gelesen**, beide über bestehende Wege — und es sind
+zwei verschiedene: eine Kundeninstanz wird über den **Proxmox-Gastagenten**
+angesprochen (`guestExec`, so wie jeder `occ`-Aufruf im Produkt), ein Host per
+**SSH** durch den Tunnel.
 
 ### Kundeninstanz — die Nextcloud-Protokolldatei
 
@@ -297,10 +300,11 @@ sperren, wieder eintragen was noch gilt.
 
 ## 7. Bekannte Grenzen
 
-**Eine SSH-Verbindung je Instanz und Minute.** Bei der heutigen Größe ist das
-nichts. Bei hundert Instanzen sind es hundert Verbindungen pro Minute — dann
-braucht es einen anderen Weg (ein Melder im Gast, der meldet, statt gefragt zu
-werden). Das steht hier als bekannte Grenze, nicht als Überraschung für später.
+**Ein Aufruf je Instanz und Minute** über den Proxmox-Gastagenten, dazu eine
+SSH-Verbindung je Host. Bei der heutigen Größe ist das nichts. Bei hundert
+Instanzen sind es hundert Aufrufe pro Minute — dann braucht es einen anderen Weg
+(ein Melder im Gast, der meldet, statt gefragt zu werden). Das steht hier als
+bekannte Grenze, nicht als Überraschung für später.
 
 **Geteilte Adressen.** Hinter einer Adresse können unbeteiligte Menschen
 sitzen — Büro-NAT, Mobilfunk. Sie kommen dann eine Stunde lang nicht neu