test(ci): correct RM-61 crash control entrypoint

.woodpecker/ci.yml

@@ -148,10 +148,10 @@ services:
       POSTGRES_USER: mosaic
       POSTGRES_PASSWORD: mosaic
       POSTGRES_DB: mosaic
+      PGPASSWORD: mosaic
     entrypoint:
       - /bin/sh
       - -c
-    commands:
       - |
         docker-entrypoint.sh postgres &
         postgres_pid=$$!

docs/scratchpads/1000-rm-61-ci-contract-exemption.md

@@ -51,6 +51,15 @@ Historical JSON saved locally under `.evidence/rm-61/` (not for commit). Supplie
 
 This control is red and its service record differs from #1000 (`exit_code=0` plus pod-not-found). It proves the startup-failure direction only. It does not settle the dangerous post-readiness crash/garbage-collection path.
 
+### Control 2 setup attempt — invalid, excluded from evidence
+
+- Commit: `9455cd6a2650b2b7e70f746c07933d96e5cb3d20`
+- Pipeline: #2190, exact commit match.
+- Full JSON child scan: 9 total — 7 success, 2 failure, 0 skipped/pending/running.
+- Service log: `/bin/sh: 0: -c requires an argument`.
+- Root cause: Woodpecker service `commands` did not become the third `sh -c` argument. PostgreSQL never started, so this run is **not** the post-readiness crash control and provides no discrimination evidence.
+- Focused remediation: place the script directly in the third `entrypoint` element and supply `PGPASSWORD` for the marker query. This is a control-fixture correction, not a retry of #1000 and not evidence for either verdict.
+
 ## Risks
 
 The Woodpecker Kubernetes backend may garbage-collect both genuinely failed and successfully used service pods before reconciliation. If so, the provider-visible service signature cannot safely support Option B.