fix(compose): keep the CMS opt-in so it cannot claim the CI port

On a CI-managed host scripts/ci-deploy.sh owns port 3002 through the
blue/green slots, so a compose replica of the cms service could only ever
crash-loop on EADDRINUSE — it never serves traffic, because nginx points at a
slot container. Gate the service behind the `cms` profile so a bare
`docker compose up -d` starts only byparr. Naming the service explicitly
(`docker compose up -d cms`, which is what the installer and updater already
do) still enables the profile automatically, so the compose-only install path
keeps working.

Keep the one port that is actually served (3002) and make the 2 GB ceiling
hard by capping swap at 2g as well. Drop the green compose service (3003):
the green slot only ever exists as a docker run container created by CI, so
compose no longer defines it and the two paths cannot drift apart.

The loopback override contract stays covered: proxy-config.test.mjs now
renders the configuration with --profile cms, and a new build-contract test
pins the profile and the memory limits so neither can be dropped by accident.

docker-compose.yml

@@ -1,5 +1,20 @@
 # ─────────────────────────────────────────────────────────────────────────────
-# Next.js CMS — blue/green
+# Next.js CMS — single slot on port 3002
+#
+# ── Eigenaar van poort 3002 ─────────────────────────────────────────────────
+# Deze repo kent twee deploy-paden die allebei op poort 3002 willen:
+#   * `scripts/ci-deploy.sh` (blue/green, docker run) — de eigenaar op een
+#     CI-host. Elke push naar main bouwt daar een nieuwe image, draait de
+#     migrations en zet nginx pas om na health + e2e + imaging.
+#   * deze compose-`cms`-service — bedoeld voor een LOSSE host zonder CI.
+#
+# Ze kunnen niet naast elkaar draaien: wie op 3002 zit, blokkeert de ander met
+# `EADDRINUSE`. Daarom staat `cms` achter een profile. Een bloot
+# `docker compose up -d` start dus alleen byparr en kan nooit de live CI-release
+# van de site drukken. De service start alleen als je hem expliciet noemt
+# (`docker compose up -d cms`, `docker compose build cms`, ...): Compose schakelt
+# het profile van een expliciet genoemde service vanzelf in. Op een CI-host wil
+# je dat dus juist NOOIT doen.
 # ─────────────────────────────────────────────────────────────────────────────
 x-cms: &cms
   image: epicnext-cms:${CMS_RELEASE:-local}
@@ -14,8 +29,8 @@ x-cms: &cms
     dockerfile: Dockerfile
     args:
       NEXT_DEPLOYMENT_ID: ${CMS_RELEASE:-unknown}
-  # Runtime host networking IS required: blue/green needs per-release host ports
-  # (3002/3003) and nginx reaches the slot over 127.0.0.1.
+  # Runtime host networking IS required: nginx reaches the CMS over 127.0.0.1
+  # on the single port that is actually served (3002).
   network_mode: host
   stop_grace_period: 15s
   restart: unless-stopped
@@ -28,8 +43,8 @@ x-cms: &cms
     - /var/www/Gamedata:/var/www/Gamedata
 
   # ── Resource limits ──
-  mem_limit: 6g
-  memswap_limit: 7g
+  mem_limit: 2g
+  memswap_limit: 2g
   cpus: 2.0
   pids_limit: 512
 
@@ -43,19 +58,13 @@ x-cms: &cms
 services:
   cms:
     <<: *cms
+    # Alleen starten als je deze host bewust compose-only beheert.
+    profiles: ["cms"]
     container_name: epicnext-cms
     environment:
       - HOSTNAME=0.0.0.0
       - PORT=3002
 
-  cms-green:
-    <<: *cms
-    container_name: epicnext-cms-green
-    profiles: ["green"]
-    environment:
-      - HOSTNAME=0.0.0.0
-      - PORT=3003
-
   byparr:
     image: ghcr.io/thephaseless/byparr:latest
     container_name: byparr