fix(deploy/test) + ci(guard): drop dead SCEP profile from test compose

The deploy-vendor-e2e job has been failing with the certctl-test-server
container restarting endlessly. Diagnostic dump (added in 69266c8)
finally surfaced the actual cause:

    Failed to load configuration: SCEP profile 0 (PathID="e2eintune")
    has empty CHALLENGE_PASSWORD — refuse to start (CWE-306: per-profile
    shared secret is the sole application-layer auth boundary; an empty
    password would allow any client reaching /scep/e2eintune to enroll
    a CSR against issuer "iss-local")

Same shape as the encryption-key fix that landed in 4bb7a74: a config
validation gate added in code that the test compose never got updated
to satisfy, hidden pre-Phase-5 because the matrix-collapse hadn't yet
forced the certctl-server to actually boot in CI.

Root cause is more interesting than just "missing env var." The
2026-04-29 SCEP RFC 8894 + Intune master bundle Phase I added an
`e2eintune` SCEP profile to docker-compose.test.yml expecting
deploy/test/scep_intune_e2e_test.go to exercise it. That integration
test does exist (//go:build integration) but **NO CI job ever
selects it** — ci.yml's deploy-vendor-e2e job runs only
`-run 'VendorEdge_'` (line 379), and no other job invokes
`go test -tags integration` with a SCEP selector. Confirmed via
`grep -rnE "scep_intune|SCEPIntune" .github/workflows/` returning
empty.

Worse: the supporting fixtures (ra.crt + ra.key + intune_trust_anchor.pem)
were documented in deploy/test/fixtures/README.md with the
regeneration recipe but never actually committed. Pre-Phase-5 the
test stack didn't fully boot the server in CI, so the entire stack
of debt — dead config + missing fixtures + no consumer test — sat
silent until the matrix collapse forced the boot path.

Fixing this with a fake CHALLENGE_PASSWORD value would silence the
immediate validator but leave the real problem in place: maintenance
cost on test config that no test exercises. Same critique applies
to "let me commit fake fixtures" — the fixtures alone don't add
test coverage when no CI job runs the SCEP test.

The complete-path fix is to make the test compose match what CI
actually exercises:

  - deploy/docker-compose.test.yml: drop CERTCTL_SCEP_ENABLED + the
    full e2eintune profile env var family (10 lines) + the
    ./test/fixtures volume mount (1 line). Replace with an in-line
    comment explaining why SCEP is intentionally disabled and what
    needs to come back together when SCEP is added to CI for real.

  - scripts/ci-guards/test-compose-scep-coherence.sh (new, 22nd
    guard): refuses any future state where CERTCTL_SCEP_ENABLED=true
    in test compose without ALL of:
      1. A CI job that runs the SCEP integration test (matched by
         scep_intune | SCEPIntune | -run [Ss]cep in ci.yml)
      2. The fixture files actually committed (ra.crt, ra.key,
         intune_trust_anchor.pem)
      3. The ./test/fixtures:/etc/certctl/scep:ro volume mount
    Verified manually with the same pattern as the H-1 guard:
    clean tree → exit 0; deliberate SCEP_ENABLED=true regression →
    exit 1 with 5 ::error:: annotations covering each gap; restore
    → exit 0 again.

  - scripts/ci-guards/README.md: 21 → 22 guards, new row.

The fixtures README at deploy/test/fixtures/README.md keeps the
regeneration recipe so the eventual SCEP CI job lands cleanly: the
operator who adds the SCEP job restores the env vars, regenerates
+ commits the fixtures, and the guard auto-passes.

Pattern (now firm across this CI-stabilization sequence):
  - Pre-existing latent bug
  - Old CI structurally hid it (per-vendor matrix, missing boot path)
  - Phase-5 matrix collapse + new diagnostic infra exposed it
  - Direct fix unblocks today
  - Regression guard prevents the same shape of drift forever

Encryption-key (4bb7a74) was the same shape; this is its sibling.

scripts/ci-guards/README.md

@@ -53,7 +53,7 @@ Current helpers:
 4. CI auto-picks up new scripts via the `for g in scripts/ci-guards/*.sh`
    loop in the `Regression guards` step — no ci.yml change required.
 
-## The 21 guards in this directory
+## The 22 guards in this directory
 
 | ID | Finding | Catches |
 |---|---|---|
@@ -78,6 +78,7 @@ Current helpers:
 | `bundle-8-L-019-dangerously-set-inner-html` | L-019 (CWE-79) XSS | `dangerouslySetInnerHTML` outside `safeHtml.ts` |
 | `bundle-8-M-009-bare-usemutation` | M-009 + M-029 mutation contract | Bare `useMutation()` outside `useTrackedMutation` wrapper |
 | `H-1-encryption-key-min-length` | H-1 closure follow-up (post-Phase-5 surfacing) | `CERTCTL_CONFIG_ENCRYPTION_KEY` literal in any `deploy/docker-compose*.yml` shorter than the 32-byte floor enforced by `internal/config/config.go::Validate()` |
+| `test-compose-scep-coherence` | post-Phase-5 surfacing of dead SCEP test config | `CERTCTL_SCEP_ENABLED=true` in test compose without (a) a CI job that runs the SCEP integration test, (b) the `ra.crt` + `ra.key` + `intune_trust_anchor.pem` fixtures committed to `deploy/test/fixtures/`, AND (c) the matching volume mount |
 
 ## Guards explicitly NOT here
 

scripts/ci-guards/test-compose-scep-coherence.sh

@@ -0,0 +1,85 @@
+#!/usr/bin/env bash
+# scripts/ci-guards/test-compose-scep-coherence.sh
+#
+# Enforces that deploy/docker-compose.test.yml's SCEP profile config
+# stays coherent with the rest of the test infrastructure: if SCEP is
+# enabled in test compose, then there MUST be a CI job that exercises
+# the SCEP integration test, AND the supporting fixture files must
+# actually exist on disk (not just be documented in the fixtures README).
+#
+# Background. The 2026-04-29 SCEP RFC 8894 + Intune master bundle
+# Phase I added an `e2eintune` SCEP profile to docker-compose.test.yml
+# expecting deploy/test/scep_intune_e2e_test.go to exercise it. The
+# test exists (//go:build integration) but was never wired into any
+# CI job, AND the supporting fixtures (ra.crt + ra.key +
+# intune_trust_anchor.pem) were documented in deploy/test/fixtures/
+# README.md but never committed. Pre-Phase-5 (ci-pipeline-cleanup
+# matrix collapse) the test stack didn't fully boot the certctl-server,
+# so the gap was hidden. Post-collapse the boot validator at
+# config.go::Validate() fired with CWE-306 (empty CHALLENGE_PASSWORD)
+# and blocked deploy-vendor-e2e.
+#
+# That bundle's CI commit (this guard's predecessor commit) dropped the
+# SCEP env vars + the fixtures volume mount from compose. This guard
+# stops the same drift from ever recurring silently. To re-enable SCEP
+# in test compose:
+#
+#   1. Restore the SCEP env vars (CERTCTL_SCEP_ENABLED=true +
+#      CERTCTL_SCEP_PROFILES + per-profile CHALLENGE_PASSWORD + ...).
+#   2. Restore the volume mount `./test/fixtures:/etc/certctl/scep:ro`.
+#   3. Commit the supporting fixtures (ra.crt, ra.key,
+#      intune_trust_anchor.pem) per deploy/test/fixtures/README.md.
+#   4. Add a CI job that runs `go test -tags integration -run 'SCEPIntune'`
+#      against the same compose stack — without it, the SCEP plumbing
+#      in test compose is paying maintenance cost for zero benefit.
+#
+# All four must move together. This guard refuses any partial state.
+#
+# Per the contract documented in scripts/ci-guards/README.md:
+# bare callable, no args, no env, exit 0 on clean.
+
+set -e
+
+GUARD_NAME="test-compose-scep-coherence"
+COMPOSE_FILE="deploy/docker-compose.test.yml"
+CI_FILE=".github/workflows/ci.yml"
+FIXTURES_DIR="deploy/test/fixtures"
+
+failed=0
+
+# Phase 1: is SCEP enabled in test compose? Match `CERTCTL_SCEP_ENABLED:`
+# followed by an optional quote then `true`.
+if grep -qE '^\s*CERTCTL_SCEP_ENABLED:\s*"?true"?\s*$' "$COMPOSE_FILE"; then
+  echo "Detected CERTCTL_SCEP_ENABLED=true in $COMPOSE_FILE"
+
+  # Phase 2: is there a CI job that runs the SCEP integration test?
+  # Match either an explicit selector (-run 'SCEPIntune' or similar) or
+  # a direct reference to scep_intune_e2e_test.go.
+  if ! grep -qE "scep_intune|SCEPIntune|SCEPProfile.*E2E|-run.*[Ss]cep" "$CI_FILE"; then
+    echo "::error file=${CI_FILE}::CERTCTL_SCEP_ENABLED=true in ${COMPOSE_FILE} but no CI job runs the SCEP integration test. Add a job that invokes 'go test -tags integration -run SCEPIntune' against the same compose stack, OR remove the SCEP env vars from compose."
+    failed=1
+  fi
+
+  # Phase 3: are the required fixture files present?
+  for f in ra.crt ra.key intune_trust_anchor.pem; do
+    if [ ! -f "${FIXTURES_DIR}/${f}" ]; then
+      echo "::error file=${COMPOSE_FILE}::CERTCTL_SCEP_ENABLED=true in ${COMPOSE_FILE} but required SCEP fixture is missing: ${FIXTURES_DIR}/${f}. See ${FIXTURES_DIR}/README.md for the regeneration recipe."
+      failed=1
+    fi
+  done
+
+  # Phase 4: is the volume mount present? Without it, the cert/key
+  # paths inside the container resolve to nothing.
+  if ! grep -qE '^\s*-\s+\./test/fixtures:/etc/certctl/scep:ro\s*$' "$COMPOSE_FILE"; then
+    echo "::error file=${COMPOSE_FILE}::CERTCTL_SCEP_ENABLED=true but the './test/fixtures:/etc/certctl/scep:ro' volume mount is missing. SCEP profile would have no fixture access."
+    failed=1
+  fi
+fi
+
+if [ "$failed" -ne 0 ]; then
+  echo ""
+  echo "${GUARD_NAME}: FAILED — SCEP test config is incoherent across compose, CI workflow, and fixtures."
+  exit 1
+fi
+
+echo "${GUARD_NAME}: clean."