ci-pipeline-cleanup Phase 1: extract 20 regression guards to scripts/ci-guards/

Bundle: ci-pipeline-cleanup, Phase 1.

Pure relocation — no behavior change. Each guard's bash logic is
byte-identical to the prior inline version; the only changes are:
(a) the guard becomes a sibling script under scripts/ci-guards/<id>.sh,
(b) ci.yml's per-guard step is replaced by a single loop step that
iterates all scripts.

20 scripts extracted (alphabetized):
  B-1-orphan-crud.sh, D-1-D-2-statusbadge-phantom.sh,
  G-1-jwt-auth-literal.sh, G-2-api-key-hash-json.sh,
  G-3-env-docs-drift.sh, H-001-bare-from.sh, H-009-readme-jwt.sh,
  L-001-insecure-skip-verify.sh, L-1-bulk-action-loop.sh,
  M-012-no-root-user.sh, P-1-documented-orphan-fns.sh,
  S-1-hardcoded-source-counts.sh, S-2-strings-contains-err.sh,
  T-1-frontend-page-coverage.sh, U-2-plaintext-healthcheck.sh,
  U-3-migration-mount.sh, bundle-8-L-015-target-blank-rel-noopener.sh,
  bundle-8-L-019-dangerously-set-inner-html.sh,
  bundle-8-M-009-bare-usemutation.sh, test-naming-convention.sh

Plus scripts/ci-guards/README.md documenting the contract:
- Each script must exit 0 on clean repo, non-zero with ::error::
  prefix on regression
- Runnable from repo root via 'bash scripts/ci-guards/<id>.sh'
- Adding a new guard: drop a new <id>.sh; CI auto-picks it up

ci.yml dropped 1488 → 557 lines (-931, -63%).

Single CI loop step now collects ALL guard failures before failing
the build instead of fail-fast — UX win for regressions that hit
two guards at once.

Two guards (QA-doc Part-count + seed-count, ci.yml lines 868-917)
deliberately NOT extracted — they move to 'make verify-docs' in
Phase 11 because they protect docs-the-operator-reads, not the
product itself.

Verification (sandbox):
- All 20 scripts pass against HEAD (chmod +x; for g in scripts/ci-guards/*.sh; do bash $g; done)
- New ci.yml YAML-parses cleanly
- Job boundaries preserved: go-build-and-test, frontend-build,
  helm-lint, deploy-vendor-e2e, deploy-vendor-e2e-windows
- Loop step appears twice (once at end of go-build-and-test, once
  at end of frontend-build) so both jobs continue running their
  set of guards

scripts/ci-guards/H-009-readme-jwt.sh

@@ -0,0 +1,28 @@
+#!/usr/bin/env bash
+# scripts/ci-guards/H-009-readme-jwt.sh
+#
+# H-009 closed by Bundle D as verified-already-clean: at audit time
+# the README does NOT advertise JWT support (certctl does not ship
+# in-process JWT middleware; JWT/OIDC integration is via an
+# authenticating gateway, see docs/architecture.md "Authenticating-
+# gateway pattern"). This script grep-fails the build if README ever
+# re-introduces a sentence advertising JWT as a supported auth mode.
+# Pattern: "JWT" within ~6 words of "support|auth|enabled|mode" in
+# README.md. The architecture / compliance / connector docs that
+# legitimately mention JWT (Google OAuth2 service-account JWT,
+# step-ca provisioner JWT, JWT-via-gateway pattern) are out of
+# scope — they describe what certctl does NOT do, or external
+# protocol uses.
+
+set -e
+if grep -inE 'JWT.{0,40}(support|auth|enabled|mode|provider)' README.md \
+   | grep -v 'gateway' | grep -v 'pre-G-1'; then
+  echo "::error::H-009 regression: README.md appears to advertise JWT auth support."
+  echo "certctl does NOT ship in-process JWT middleware. JWT/OIDC"
+  echo "integration is via an authenticating gateway — see"
+  echo "docs/architecture.md::Authenticating-gateway pattern."
+  echo "If you added a sentence about JWT to README, either remove"
+  echo "it or rewrite it to point at the gateway pattern."
+  exit 1
+fi
+echo "H-009 readme-jwt: clean."