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/bundle-8-L-019-dangerously-set-inner-html.sh

@@ -0,0 +1,30 @@
+#!/usr/bin/env bash
+# scripts/ci-guards/bundle-8-L-019-dangerously-set-inner-html.sh
+#
+# Audit L-019 / CWE-79 (XSS): no PRODUCTION code may use
+# dangerouslySetInnerHTML directly. At Bundle-8 close the codebase
+# has 0 sites; future genuine needs MUST route through
+# web/src/utils/safeHtml.ts::sanitizeHtml.
+#
+# Test files (web/src/**/*.test.{ts,tsx}) are explicitly excluded:
+# the M-029 Pass 3 XSS-hardening test docstrings legitimately cite
+# the attack vector by name to explain what the test is guarding
+# against (e.g. "a careless refactor to dangerouslySetInnerHTML
+# would let an attacker-controlled CSR deliver an XSS payload").
+# Tests describing the threat aren't using it; the guard's intent
+# is production code only.
+
+set -e
+OFFENDERS=$(grep -rnE 'dangerouslySetInnerHTML' web/src/ 2>/dev/null \
+  | grep -v 'web/src/utils/safeHtml.ts' \
+  | grep -vE '\.test\.(ts|tsx)(:[0-9]+)?:' \
+  || true)
+if [ -n "$OFFENDERS" ]; then
+  echo "::error::L-019 regression: dangerouslySetInnerHTML used outside safeHtml.ts:"
+  echo "$OFFENDERS"
+  echo ""
+  echo "Route through web/src/utils/safeHtml.ts::sanitizeHtml — see file"
+  echo "header for the activation procedure (DOMPurify dependency)."
+  exit 1
+fi
+echo "L-019 dangerously-set-inner-html: clean."