fix: Host-Ports in die Grunddatei, hostports.yml entfaellt

Der Stack lief, meldete alle Container gesund — und beide Adressen gaben 502.
Grund: kein einziger Port veroeffentlicht. Die standen in
docker-compose.hostports.yml, und Portainer hat die nicht angewandt.

Das war mein Anleitungsfehler. Ich hatte geschrieben, man koenne unter
"Compose path" zwei Pfade mit Komma angeben. Portainer nimmt dort EINE Datei.
Die Ergaenzung wurde nicht etwa abgelehnt, sondern stillschweigend ignoriert —
die schlechteste Art zu scheitern, weil danach alles gesund aussieht.

Eine Trennung, die man nicht anwenden kann, ist keine. Die Ports stehen jetzt
in docker-compose.yml, wo dieser Server sie ohnehin braucht.

docker-compose.proxynet.yml bleibt als der sauberere Weg fuer einen Proxy im
selben Docker-Netz, jetzt aber mit dem Hinweis, dass er ueber Portainer-aus-
Repo nicht zu haben ist. Hier trifft er nicht zu: NPM liegt auf 172.17.0.3 im
Standard-Bridge-Netz.

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

README.md

@@ -44,43 +44,12 @@ Die Werte gehören **in die Stack-Variablen**, nicht in eine Datei im Repo.
 
 ### Wie der Reverse Proxy die Dienste erreicht
 
-`docker-compose.yml` allein ist von außen **nicht erreichbar** — das ist
-Absicht. Wie der Proxy die Dienste findet, hängt am Aufbau, also wählst du eine
-Ergänzung dazu. In Portainer beide Pfade unter *Compose path*, mit Komma:
-
-**A · Der Proxy hängt im selben Docker-Netz** — der sauberere Weg, kein Port
-muss offen sein.
+Über den **Host**, und das steht fertig in `docker-compose.yml`. Genauso laufen
+`d4rkbot` auf 3080 und `cdn-files` auf 8090 schon.
 
 ```
-docker-compose.yml,docker-compose.proxynet.yml
-```
-
-Dazu `PROXY_NETWORK` auf den Namen des Netzes setzen, in dem der Proxy hängt.
-Welches das ist, zeigt Portainer unter *Networks* oder:
-
-```bash
-docker network ls
-docker network inspect <name>      # zeigt die Mitglieder
-```
-
-Auf **diesem** Server ist es nicht so: der NPM-Container hat `172.17.0.3` und
-liegt damit im Standard-Bridge-Netz, nicht in `web`. Hier gilt Weg B.
-
-```
-fivecdn.d4rkst3r.de  ->  http://minio:9000
-<oberfläche>         ->  http://lite:8080
-```
-
-**B · Der Proxy erreicht die Dienste über den Host** — *das ist hier der Fall.*
-So laufen `d4rkbot` auf 3080 und `cdn-files` auf 8090 schon.
-
-```
-docker-compose.yml,docker-compose.hostports.yml
-```
-
-```
-fivecdn.d4rkst3r.de  ->  http://host.docker.internal:9100
-<oberfläche>         ->  http://host.docker.internal:9101
+fivecdn.d4rkst3r.de   ->  http://host.docker.internal:9100
+fivemanage.d4rkst3r.de ->  http://host.docker.internal:9101
 ```
 
 **Nicht 9000 und 8080** — die sind auf diesem Server vergeben (Portainer und
@@ -88,6 +57,27 @@ nextcloud-aio). Im Container bleibt es bei 9000 und 8080; nur die Seite zum
 Host wandert. Kollidiert später noch etwas, sind es zwei Variablen:
 `MINIO_HOST_PORT` und `LITE_HOST_PORT`.
 
+Die Ports sind an **alle** Adressen gebunden, nicht an `127.0.0.1`. Das ist
+kein Versehen: NPM liegt im Standard-Bridge-Netz (`172.17.0.3`) und kommt über
+die Docker-Brücke herein, nicht über Loopback — ein an `127.0.0.1` gebundener
+Port nimmt diese Anfrage nicht an. **Zu macht sie die Firewall**, nicht die
+Bindung. 9100 und 9101 gehören von außen dicht; öffentlich soll nur NPM auf
+80/443 sein.
+
+#### Wenn der Proxy im selben Docker-Netz hängt
+
+Dann geht es sauberer, ganz ohne offene Ports — dafür liegt
+`docker-compose.proxynet.yml` bereit. **Portainer nimmt unter *Compose path*
+aber nur eine Datei**; eine Ergänzung wird dort stillschweigend ignoriert. Wer
+diesen Weg will, führt die beiden Dateien zusammen oder startet den Stack von
+Hand:
+
+```bash
+docker compose -f docker-compose.yml -f docker-compose.proxynet.yml up -d
+```
+
+Auf **diesem** Server trifft das nicht zu.
+
 Die Ports sind an **alle Adressen** gebunden, weil `host.docker.internal` auf
 diesem Server über die Docker-Brücke kommt und ein `127.0.0.1`-Port die
 Anfrage nicht annähme — dieselbe Bindung, mit der `d4rkbot` und `cdn-files`