feat(vpn): expose Athena services directly over WireGuard

docs/SECURITY.md

@@ -3,8 +3,9 @@
 ## Netzgrenze
 
 - Open WebUI und Router veröffentlichen keinerlei Host-Ports.
-- Ein dedizierter WireGuard-Container stellt auf seiner VPN-Adresse nur 8080
-  und 8081 bereit.
+- Ein dedizierter WireGuard-Container stellt OpenWebUI, Router und die
+  Werkzeugdienste direkt auf seiner VPN-Adresse bereit. Die verbindliche
+  Portmatrix steht in [VPN_SERVICE_PORTS.md](VPN_SERVICE_PORTS.md).
 - Die egressfähigen Docker-Netze verwenden eigene Routingtabellen.
 - Heimnetz- und optionaler Internetverkehr laufen über WireGuard.
 - Die Tabellen zeigen ausschließlich zum Gateway-Container und besitzen keine
@@ -22,13 +23,14 @@ physischen Schnittstelle erreichbar.
 - Profile Controller: einzige Socket-Ausnahme; feste Profile und nur
   List/Start/Stop, keine frei wählbaren Images, Befehle oder Mounts.
 - Open WebUI: einziges persistentes Chat-Volume.
-- MCP-Fachcontainer: intern, getrennte Secrets und keine Host-Ports.
+- MCP-Fachcontainer: intern verbunden und über feste WireGuard-Ports direkt
+  für OpenWebUI, Pi, Hermes und andere Heim-VPN-Clients erreichbar.
 - TinySearch/SearXNG: intern, Suchanfragen ohne Chatverlauf.
 
 llama.cpp bekommt weder MCP-Konfiguration noch HA-, ARR- oder Unraid-Secrets.
-Open WebUI kennt nur interne MCP-URLs; Authentisierung zu den Zielsystemen
-findet im jeweiligen Fachcontainer statt. Externe MCP-Clients werden erst über
-einen authentifizierten WireGuard-Gateway zugelassen.
+Open WebUI kann weiterhin die internen MCP-Namen verwenden. Andere Clients
+nutzen ohne zusätzliches Gateway die festen MCP-Ports der WireGuard-Adresse.
+Authentisierung zu den Zielsystemen findet im jeweiligen Fachcontainer statt.
 
 Ein Docker-Socket bleibt grundsätzlich privilegiert. Der Controller reduziert
 die erreichbare Funktion stark, ersetzt aber keine zusätzliche Socket-Proxy-