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 3b96b35)
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 c4157fd: 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 (c4157fd) was the same shape; this is its sibling.

deploy/docker-compose.test.yml

@@ -284,26 +284,34 @@ services:
       CERTCTL_EST_ENABLED: "true"
       CERTCTL_EST_ISSUER_ID: iss-local
 
-      # SCEP RFC 8894 + Intune master prompt §10.2 + §13 acceptance
-      # (deploy/test/scep_intune_e2e_test.go integration variant).
-      # Closed in the 2026-04-29 audit-closure bundle (Phase I).
+      # SCEP intentionally NOT configured in this stack.
       #
-      # Publishes /scep/e2eintune?operation=... with the Intune
-      # dispatcher enabled. The deterministic Connector signing cert
-      # is bind-mounted at the path below; the matching private key
-      # lives ONLY on the test side (see
-      # deploy/test/scep_intune_e2e_test.go::generateE2EIntuneTrustAnchor).
-      CERTCTL_SCEP_ENABLED: "true"
-      CERTCTL_SCEP_PROFILES: "e2eintune"
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_ISSUER_ID: iss-local
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_RA_CERT_PATH: /etc/certctl/scep/ra.crt
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_RA_KEY_PATH: /etc/certctl/scep/ra.key
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_ENABLED: "true"
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_CONNECTOR_CERT_PATH: /etc/certctl/scep/intune_trust_anchor.pem
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_AUDIENCE: https://localhost:8443/scep/e2eintune
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_CHALLENGE_VALIDITY: 60m
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_CLOCK_SKEW_TOLERANCE: 60s
-      CERTCTL_SCEP_PROFILE_E2EINTUNE_INTUNE_PER_DEVICE_RATE_LIMIT_24H: 3
+      # The 2026-04-29 master bundle Phase I added an `e2eintune` SCEP
+      # profile to this compose file with the intent that
+      # deploy/test/scep_intune_e2e_test.go would exercise it. That
+      # integration test exists (//go:build integration) but no CI job
+      # actually selects it — ci.yml's deploy-vendor-e2e job runs only
+      # `-run 'VendorEdge_'` (line 379), and no other job ever invokes
+      # `go test -tags integration` with a SCEP selector.
+      #
+      # The result was dead config: SCEP_ENABLED=true triggered the
+      # per-profile validator chain at server boot, but the supporting
+      # fixtures (ra.crt + ra.key + intune_trust_anchor.pem) were never
+      # committed to deploy/test/fixtures/ — only the README documenting
+      # how to regenerate them. Pre-Phase-5 (ci-pipeline-cleanup matrix
+      # collapse) the test stack didn't fully boot the certctl-server in
+      # CI, so the gap was hidden. Once the matrix collapsed and the
+      # collapsed deploy-vendor-e2e job started actually booting the
+      # server, the fail-loud gate at config.go:2069 (CWE-306, empty
+      # CHALLENGE_PASSWORD) fired and blocked CI.
+      #
+      # CERTCTL_SCEP_ENABLED is unset → default false → the validator
+      # skips the entire SCEP block. Coherence guard at
+      # scripts/ci-guards/test-compose-scep-coherence.sh refuses any
+      # future edit that re-enables SCEP without ALSO (a) adding a CI
+      # job that runs the SCEP integration test and (b) committing the
+      # required fixtures. The README at deploy/test/fixtures/README.md
+      # keeps the regen recipe so the eventual SCEP CI job lands cleanly.
 
       # Dynamic issuer/target config encryption (M34/M35).
       #
@@ -346,15 +354,11 @@ services:
       # agent mounts the same host path at the same container path (see below)
       # so /etc/certctl/tls/ca.crt resolves to the *same* bytes on both sides.
       - ./test/certs:/etc/certctl/tls:ro
-      # SCEP RFC 8894 + Intune master prompt §10.2 + §13 acceptance: the
-      # e2eintune profile's RA cert/key + Intune Connector trust anchor
-      # PEM. The PEM is the deterministic public cert matching the test-
-      # side private key in deploy/test/scep_intune_e2e_test.go (re-run
-      # `go test -tags integration -run='^TestRegenerateE2EIntuneFixture$'
-      # -update-fixture ./deploy/test/...` to regenerate after a seed
-      # change). RA cert/key live alongside; tls-init container generates
-      # them at boot.
-      - ./test/fixtures:/etc/certctl/scep:ro
+      # SCEP fixtures volume mount removed alongside the SCEP env vars
+      # above. When a CI job that runs scep_intune_e2e_test.go is added,
+      # restore both this mount AND the env vars together — the coherence
+      # guard at scripts/ci-guards/test-compose-scep-coherence.sh
+      # enforces that they move as a unit.
     networks:
       certctl-test:
         ipv4_address: 10.30.50.6