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.

README.md

@@ -965,11 +965,13 @@ there are two fixed slots, and each release lands in the idle one:
 | A | 3002 | `epicnext-cms-app` |
 | B | 3003 | `epicnext-cms-green` |
 
-`docker-compose.yml` defines both services (`cms`, and `cms-green` behind the
-`green` profile) from one shared YAML anchor so they cannot drift apart. Note
-that the CI deploy path deliberately uses `docker run` rather than compose, so
-the resource limits are declared in **both** places — limits that only existed
-in compose would never apply to a real release.
+`docker-compose.yml` defines a single `cms` service (the blue slot on 3002)
+behind the `cms` profile, so a bare `docker compose up -d` never starts it. The
+green slot (`epicnext-cms-green`, port 3003) only ever exists as a `docker run`
+container created by the CI deploy; compose does not define it, so the two paths
+cannot drift apart. Note that the CI deploy path deliberately uses `docker run`
+rather than compose, so the resource limits are declared in **both** places —
+limits that only existed in compose would never apply to a real release.
 
 ### Compose on a CI host
 
@@ -977,9 +979,14 @@ Compose and CI both want port 3002, so only one of them can own a host. A stray
 compose replica (`docker compose up`, or the daily `scripts/docker-update.sh`
 cron) parked an `epicnext-cms` container on the blue slot while nginx served the
 green slot, and every later release stopped on "Port 3002 is already in use" —
-after the build, the migrations and the browser gate. Two guards now prevent
+after the build, the migrations and the browser gate. Three guards now prevent
 that:
 
+- The `cms` service sits behind the `cms` profile, so a bare `docker compose up
+  -d` starts only byparr and can never claim 3002. The service starts only when
+  it is named explicitly (`docker compose up -d cms`), which is what the
+  installer/updater already do; Compose enables the profile automatically for an
+  explicitly named service.
 - `scripts/docker-update.sh` refuses to run on a CI host. It used to test only
   `epicnext-cms-app`, but after a cutover to the green slot that container is
   stopped and deleted, so the guard stopped firing while the host stayed