fix: complete deployment release gates

README.md

@@ -91,42 +91,67 @@ later with `docker compose --project-name "$SMOKE_PROJECT" down --volumes`.
 
 ## Unified deployment release gates
 
-Task 13 adds a no-secret release gate around the canonical base plus local Compose profile. Its
+Task 13 adds no-secret release gates around the canonical local and server Compose profiles. Its
 deterministic safety check does not contact the Docker daemon:
 
 ```sh
 bash scripts/unified-deployment-smoke.sh --self-test
 ```
 
-The two Docker smokes are separate release jobs. Each creates a unique Compose project, temporary
+The three Linux Docker smokes are separate release commands. Each creates a unique Compose project, temporary
 Git workspace remote, fixture provider, image names, and run label. Its exit trap removes only
-resources carrying that exact run identity and never performs a global Docker prune.
+resources carrying that exact run identity and never performs a global Docker prune. Cleanup
+enumerates running and stopped project containers immediately before `compose down` and refuses
+the teardown if any container, volume, or network has a foreign run label.
 
 ```sh
 bash scripts/unified-deployment-smoke.sh
 bash scripts/thothctl-update-smoke.sh
+bash scripts/server-deployment-smoke.sh
 ```
 
 The unified smoke builds and starts `frontend` and `core`, verifies the embedded Pi and internal
 registry, recreates with the Git remote offline, activates a valid Git update, rejects invalid Git
-content while retaining the valid snapshot, and checks the four persistence volumes. Both smokes
+content while retaining the valid snapshot, and checks the four persistence volumes. The unified
+and update-only smokes
 inject a digest-pinned non-core candidate under a deliberately mismatched Pi version and require
 `thothctl pi update` to roll back while preserving settings, sessions, Pi state, registry revision,
-and mount identity. Fixture credentials are generated locally; neither command needs a real
-provider key or a repository secret. CI gives each smoke one 30-minute outer timeout and does not
-retry it.
+and mount identity. The rollback candidate is the digest-pinned `hello-world` executable: a
+preflight proves that it exits successfully, so the failed replacement core satisfies
+`thothctl`'s stopped-core compensation precondition. The server smoke uses the same smoke-built
+core/frontend images with the server and required session overlays, disposable bind roots and
+secret files, upstream-auth checks, and a fail-closed `503` assertion for its deliberately
+unavailable disposable session endpoint. No real provider, database credential, or repository
+secret is required.
 
-On a native Windows clone, the release contract is:
+Each public smoke has its own 30-minute process-group supervisor with TERM/KILL cleanup; CI retains
+an independent 32-minute outer timeout and does not retry a failed command.
+
+Current release status (2026-08-05): deterministic contracts are green, but the complete rollback
+fixture has not passed end to end after its runtime-binding correction. The one observed local
+server-profile run also stopped before startup because Docker Desktop/VirtioFS rejected the
+profile's parent Pi-state bind with nested tracked agent-file binds. A fresh single rollback run,
+native-Linux server-profile run, and native Windows Docker Desktop/WSL2 run remain release gates;
+the project does not claim those criteria green.
+
+The deterministic native Windows contract is:
 
 ```powershell
-.\scripts\test-windows-clone-contract.ps1 `
-  -ThothctlPath "$PWD\dist\thothctl\thothctl-windows-amd64.exe"
+.\scripts\test-windows-clone-contract.ps1
 ```
 
-It checks Git's CRLF/LF attributes and bytes, renders exactly `core` plus `frontend` with Docker
-Compose without starting containers, and invokes the native Windows `thothctl`. The GitHub Actions
-deployment workflow runs the deterministic Linux gates, both bounded Docker smokes, and this
-Windows clone contract with immutable action pins and supported pinned Node/Go toolchains.
+It checks Git's CRLF/LF attributes and bytes, copies tracked source into a temporary path containing
+spaces, builds and invokes native Windows `thothctl` there, and renders exactly `core` plus
+`frontend` without starting containers. On a supported self-hosted Windows Docker Desktop/WSL2
+runner, dispatch the deployment workflow with `windows_docker_startup=true`; that job executes:
+
+```powershell
+.\scripts\test-windows-clone-contract.ps1 -DockerStartup
+```
+
+Startup mode adds bounded image build/two-service health startup, installation-aware `thothctl`
+status, stopped-container-aware ownership checks, and exact cleanup. The ordinary hosted Windows
+job remains deterministic and does not claim Docker startup.
 
 ## Optional local pgvector and recovery