ci: don't run the install rehearsal on the production gateway

Every other step in the release job is inert with respect to prod — build,
SBOM, sign, offline verify. The rehearsal is the only one whose purpose is to
stand a full stack up and tear it down with `down -v`, and it was doing that on
the machine serving production. On 2026-08-13 it adopted the live compose
project and destroyed clawmates_pgdata.

The script itself is now safe (unique -p, a guard against the production project
name, and a health probe pointing at the port the bundle actually publishes) and
is kept for use on a build box or throwaway VM. What changes here is only WHERE
it runs, which was the real problem: a destructive verification step does not
belong on the host it can destroy.

Releases still build, sign, verify offline in a --network none container, and
upload to Gitea.

Co-Authored-By: Claude Opus 5 <[email protected]>

.gitea/workflows/release.yml

@@ -149,22 +149,27 @@ jobs:
       - name: Tarball
         run: tar -C dist -czf "clawmates-bundle-$VERSION.tgz" bundle
 
-      - name: Clean-room install rehearsal
+      # The clean-room install rehearsal is DELIBERATELY NOT RUN HERE.
-        run: |
+      #
-          set -eu
+      # Every other step in this job is inert with respect to production: it
-          docker tag "clawmates/server:$VERSION"   clawmates/server:latest
+      # builds images, writes SBOMs, signs a bundle, and verifies it in a
-          docker tag "clawmates/frontend:$VERSION" clawmates/frontend:latest
+      # network-isolated container. The rehearsal is the one step whose entire
-          docker tag "clawmates/broker:$VERSION"   clawmates/broker:latest
+      # purpose is to stand a full stack UP and then tear it down with
-          # Absolute path: the script cds around, and it needs the binary we
+      # `down -v` — on the machine serving production.
-          # already built rather than a cargo this host does not have.
+      #
-          # COMPOSE points at a STANDALONE v2 binary. gw-04 intentionally has no
+      # On 2026-08-13 it did exactly that: the bundled compose file declares
-          # `docker compose` plugin: installing one would switch the production
+      # `name: clawmates`, which beat --project-directory, so the rehearsal
-          # rolling deploy (clawmates-deploy.sh) off docker-compose v1 as a side
+      # adopted the live stack and its teardown deleted clawmates_pgdata. The
-          # effect. The compose file needs v2 syntax, so the rehearsal gets its
+      # database was lost and there were no backups.
-          # own copy rather than changing what prod rolls with.
+      #
-          CLAWMATES_BUNDLER="$PWD/.tools/clawmates-bundler" \
+      # scripts/rehearse-install.sh is now isolated (`-p rehearse-$$` plus a
-          COMPOSE=/opt/act-runner/bin/docker-compose \
+      # guard that refuses the production project name) and its health probe is
-            ./scripts/rehearse-install.sh
+      # fixed, so it is safe to run — just not on this host. Run it on a build
+      # box or throwaway VM:
+      #
+      #   CLAWMATES_BUNDLER=… COMPOSE=/path/to/compose-v2 ./scripts/rehearse-install.sh
+      #
+      # Restore this step here only if the release ever moves off the gateway.
 
       # Gitea's release API, not softprops/action-gh-release (GitHub-only).
       # Create-or-reuse, so a re-run of the same tag updates instead of 409ing.