docs: retire compliance subtree + sweep framework name-drops from prose

Per operator decision the framework-mapping docs are gone. They
were aspirational (no audit, no certification, no validated
mapping); keeping them around was misleading.

Files deleted (1,883 lines):
- docs/compliance/index.md
- docs/compliance/soc2.md
- docs/compliance/pci-dss.md
- docs/compliance/nist-sp-800-57.md

Hyperlinks removed:
- README.md: 'Auditor / compliance' row in the doc table; the
  '(compliance mapping included)' parenthetical in the
  positioning paragraph
- docs/README.md: the '## Compliance' section table; the
  'Auditor / compliance team' reading-order-by-role row

Prose name-drops swept across 24 files:
- README.md: 'FedRAMP boundary CAs / financial-services policy
  CAs' → '4-level boundary CAs / 3-level policy CAs';
  'Compliance-grade for PCI-DSS Level 1, FedRAMP Moderate / High,
  SOC 2 Type II, HIPAA' → cut entirely
- getting-started/{quickstart,concepts,examples,why-certctl,
  advanced-demo}.md: 'compliance' → 'audit' / 'policy';
  'PCI-DSS / SOC 2 / NIST SP 800-57' framework lists cut;
  ''pci': 'true'' tag example → ''environment': 'production''
- migration/cert-manager-coexistence.md: 'compliance rules' →
  'policy rules'
- operator/approval-workflow.md: 'Compliance customers (PCI-DSS
  Level 1, FedRAMP Moderate / High, SOC 2 Type II, HIPAA)' →
  'Operators'; entire 'Compliance control mapping' table
  (PCI-DSS §6.4.5 / NIST SP 800-53 SA-15 / SOC 2 Type II CC6.1
  / HIPAA §164.308(a)(4)) deleted; 'compliance contract' →
  'two-person-integrity contract'; 'compliance auditors' →
  'reviewers'
- operator/legacy-clients-tls-1.2.md: 'PCI-DSS v4.0 Req 4 §2.2.5'
  audit-reference → CWE-326 (kept); 'PCI-DSS Req 4 §2.2.5
  attestation' section retitled to 'TLS posture summary' and
  rewritten without framework framing; 'PCI-DSS, NIST, and
  major browsers will eventually deprecate TLS 1.2' →
  'Major browsers and OS vendors will eventually deprecate
  TLS 1.2'
- operator/database-tls.md: PCI-DSS Req 4 §2.2.5 audit-ref →
  CWE-319 only; 'PCI-DSS scope' → 'sensitive data'; PCI-DSS
  Req 4 v4.0 prose footing → cut
- operator/runbooks/disaster-recovery.md: 'SOC 2 / PCI
  procurement-team deliverable' → 'on-call deliverable';
  'compliance auditors' → 'reviewers'
- reference/connectors/{acme,aws-acm,azure-kv,globalsign,
  local-ca,openssl,ssh,index}.md: 'compliance reporting
  (PCI-DSS §3.6, HIPAA §164.312)' → 'audit reporting';
  'Compliance environments (PCI-DSS Level 1, FedRAMP High,
  HIPAA)' → 'Regulated environments'; 'compliance audits' →
  'audit'; 'FedRAMP boundary CA' pattern names →
  '4-level boundary CA' (technically descriptive)
- reference/protocols/est.md: 'compliance-hook seam' →
  'device-state hook seam'; 'compliance gating' → 'device-state
  gating'; 'est_compliance_failed' → 'est_device_state_failed'
- reference/protocols/scep-intune.md: 'Optional compliance
  check' → 'Optional device-state check'; failure-counter
  'compliance_failed' → 'device_state_failed'; 'Conditional
  Access compliance gating' → 'Conditional Access
  device-state gating'
- reference/intermediate-ca-hierarchy.md: 'FedRAMP boundary-CA
  deployments where the regulator requires...' →
  'Boundary-CA deployments where you want separation of policy
  and issuing authorities'; pattern A retitled '4-level FedRAMP
  boundary CA' → '4-level boundary CA'
- reference/architecture.md: broken Related-docs link to
  compliance.md removed; the rest of that block had stale
  pre-Phase-2 paths (quickstart.md, demo-advanced.md,
  connectors.md, openapi.md, testing-guide.md, test-env.md) —
  retargeted to current locations
- reference/deployment-model.md: 'SOC 2 evidence-report
  generator' → 'Audit-evidence report generator'
- reference/vendor-matrix.md: 'SOC 2 / PCI auditors paste this
  into evidence packs' → 'reviewers paste this into
  vendor-evaluation packs'
- contributor/qa-test-suite.md: 'compliance exist' coverage
  description cut; 'Compliance (PCI / SOC2 / HIPAA-relevant)'
  risk-class label → 'Audit-relevant'

What was kept:
- CWE references (legitimate technical pointers)
- Microsoft API/feature names that happen to use 'compliance'
  literally ('Microsoft Graph compliance API',
  'device-compliance validators' — these are MS product names,
  not framework name-drops)
- 'NIST PQC' on the landing page (Post-Quantum Cryptography is
  the actual NIST standard family, not a compliance framework)

Verified: zero hyperlinks into docs/compliance/ remain. All 24
ci-guards/*.sh pass locally. qa-doc-seed-count.sh clean.
Net diff: 26 files / -1,883 deletions in compliance/ + -32 net
across the prose sweep.

Companion edits in cowork/ (CLAUDE.md doc-tree summary +
WORKSPACE-CHANGELOG.md retirement note) land separately.

docs/operator/legacy-clients-tls-1.2.md

@@ -2,7 +2,7 @@
 
 > Last reviewed: 2026-05-05
 
-**Audit reference:** Bundle F / M-023. PCI-DSS v4.0 Req 4 §2.2.5; CWE-326.
+**Audit reference:** Bundle F / M-023. CWE-326 (Inadequate encryption strength).
 
 ## What this is
 
@@ -15,13 +15,12 @@ proxy and pass the request through to certctl over TLS 1.3.
 
 ## Why TLS 1.3 minimum
 
-certctl's audit posture, the SOC 2 / PCI-DSS / NIST SP 800-57 compliance
-mappings, and the M-001 PBKDF2 work factor all assume modern transport
-crypto. TLS 1.2 with the cipher suites still in the wild has known
-attack surface (BEAST, POODLE, ROBOT, raccoon — all CVE-categorized);
-allowing TLS 1.2 directly on the certctl listener would invalidate the
-guarantee that the server-side encryption chain is the strongest the
-ecosystem currently supports.
+certctl's audit posture and the M-001 PBKDF2 work factor both assume
+modern transport crypto. TLS 1.2 with the cipher suites still in the
+wild has known attack surface (BEAST, POODLE, ROBOT, raccoon — all
+CVE-categorized); allowing TLS 1.2 directly on the certctl listener
+would invalidate the guarantee that the server-side encryption chain
+is the strongest the ecosystem currently supports.
 
 ## When this runbook applies
 
@@ -71,8 +70,8 @@ server {
     server_name est.example.com;
 
     # Public-facing legacy listener. ssl_protocols includes TLSv1.2 explicitly.
-    # Keep ssl_ciphers conservative — only the strong AEAD suites that
-    # PCI-DSS Req 4 §2.2.5 still allows under TLS 1.2.
+    # Keep ssl_ciphers conservative — only strong AEAD suites with forward
+    # secrecy.
     ssl_certificate     /etc/nginx/certs/est.example.com.fullchain.pem;
     ssl_certificate_key /etc/nginx/certs/est.example.com.key;
     ssl_protocols       TLSv1.2 TLSv1.3;
@@ -168,21 +167,19 @@ only one would fail loud at startup. Until that work ships, the
 header-agnostic default described above is the only supported
 configuration.
 
-## PCI-DSS Req 4 §2.2.5 attestation
+## TLS posture summary
 
-PCI-DSS v4.0 §2.2.5 ("strong cryptography for authentication/transmission
-of cardholder data") considers TLS 1.2 with strong cipher suites
-acceptable for the foreseeable future, with the explicit caveat that NIST
-or the PCI Council may shorten the deprecation window if a TLS 1.2
-weakness is published. The configuration above:
+The configuration above:
 
 - Pins TLS 1.2 + TLS 1.3 only (no SSLv3, TLS 1.0, TLS 1.1).
 - Uses only AEAD cipher suites with forward secrecy (ECDHE-* with GCM or
   ChaCha20-Poly1305).
-- Re-encrypts to TLS 1.3 on the proxy-to-certctl hop.
+- Re-encrypts to TLS 1.3 on the proxy-to-certctl hop so the certctl
+  listener never speaks anything below 1.3.
 
-This is PCI-DSS Req 4 v4.0 compliant. Auditors looking for the
-attestation should be pointed at this section + the proxy's TLS config.
+That is the strongest posture currently achievable while still allowing
+the legacy clients to enroll. Reviewers looking for the attestation
+should be pointed at this section + the proxy's TLS config.
 
 ## What this runbook does NOT cover
 
@@ -197,14 +194,11 @@ attestation should be pointed at this section + the proxy's TLS config.
 
 ## When TLS 1.2 itself sunsets
 
-PCI-DSS, NIST, and major browsers will eventually deprecate TLS 1.2.
-When that happens, this runbook becomes obsolete; the only path forward
-will be to replace the legacy clients. Subscribe to RSS feeds at the
-following sources to catch the deprecation announcement before it
-becomes a compliance failure:
-
-- https://www.pcisecuritystandards.org/news_events/
-- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/  (SP 800-52 revisions)
+Major browsers and OS vendors will eventually deprecate TLS 1.2. When
+that happens, this runbook becomes obsolete; the only path forward
+will be to replace the legacy clients. Watch the IETF TLS working
+group, the major browser vendors' announcement channels, and your
+own embedded-device vendors for deprecation notices.
 
 ## Related docs