docs: convert all 9 ASCII diagrams to mermaid

Audit of docs/ found 32 diagrams: 23 already in mermaid, 9 in ASCII
art (box-drawing chars / +-pipe boxes). Converting all 9 to mermaid
so GitHub renders them as actual diagrams in the docs preview.

Files affected (9 diagram blocks across 6 files):

  docs/architecture.md   block 1 line 706  EST request flow
  docs/architecture.md   block 2 line 798  SCEP request flow
  docs/architecture.md   block 3 line 893  Per-profile TrustAnchor +
                                           Intune challenge dispatch
  docs/architecture.md   block 4 line 935  signer.Driver interface +
                                           4 implementations
  docs/ci-pipeline.md    block 1 line 20   On-push pipeline tree
  docs/est.md            block 1 line 254  WiFi 802.1X / EAP-TLS flow
  docs/legacy-est-scep.md block 1 line 40  TLS-version-bridging proxy
  docs/qa-test-guide.md  block 1 line 41   qa_test.go to demo stack
  docs/scep-intune.md    block 1 line 39   Intune cloud chain

Conversion notes:

  - Linear flows → flowchart TD/LR. Per-step annotations that the
    ASCII had as floating text between arrows are now edge labels —
    cleaner and easier to read.
  - architecture.md block 4 (signer drivers) → flowchart LR with a
    subgraph for the Driver interface. Cleaner than a class diagram
    for the "code uses one of these implementations" semantics.
  - ci-pipeline.md tree → flowchart TD. Adds a dotted '-.depends
    on.->' arrow making the go-build-and-test → deploy-vendor-e2e
    dependency visually obvious (was a parenthetical in the ASCII).
  - est.md WiFi/RADIUS → flowchart LR with EAP, Radius, trusts,
    and EST as four distinct labeled arrows. The 'trusts' annotation
    was floating off to the side in the ASCII; now it's the arrow
    label between Radius and certctl CA.
  - All semantic detail preserved: every node label, arrow direction,
    inline annotation, and multi-line cell content carries through.

Verified: post-conversion audit shows 32 mermaid blocks, 0 ASCII.
Diff is symmetric — 108 inserts, 123 deletes — because mermaid is
slightly more compact than the box-drawing characters it replaces.

GitHub renders mermaid blocks natively in markdown previews since
2022, so all 9 diagrams now render as real flowcharts in the docs
view rather than as monospaced character art.

docs/architecture.md

@@ -703,20 +703,17 @@ The EST (Enrollment over Secure Transport) server provides an industry-standard
 
 **Architecture:** EST is a handler-level protocol that delegates certificate issuance to an existing `IssuerConnector`. This means EST is not a new issuer — it's a new *interface* to the existing issuance infrastructure. The `ESTService` bridges the `ESTHandler` to whichever issuer connector is configured via `CERTCTL_EST_ISSUER_ID`.
 
-```
+```mermaid
-Client (WiFi AP, MDM, IoT)
+flowchart TD
-    │
+    Client["Client (WiFi AP, MDM, IoT)"]
-    ▼
+    Handler["ESTHandler (handler layer)"]
-ESTHandler (handler layer)
+    Service["ESTService (service layer)"]
-    │  CSR parsing, PKCS#7 response encoding
+    Issuer["IssuerConnector (connector layer via IssuerConnectorAdapter)"]
-    ▼
+    Result["Signed certificate returned as PKCS#7 certs-only"]
-ESTService (service layer)
+    Client --> Handler
-    │  CSR validation, CN/SAN extraction, audit recording
+    Handler -->|"CSR parsing, PKCS#7 response encoding"| Service
-    ▼
+    Service -->|"CSR validation, CN/SAN extraction, audit recording"| Issuer
-IssuerConnector (connector layer via IssuerConnectorAdapter)
+    Issuer -->|"certificate signing (Local CA, step-ca, etc.)"| Result
-    │  Certificate signing (Local CA, step-ca, etc.)
-    ▼
-Signed certificate returned as PKCS#7 certs-only
 ```
 
 **Wire format:** EST uses PKCS#7 (RFC 2315) certs-only degenerate SignedData for certificate responses and base64-encoded DER for CSR requests. The handler includes a hand-rolled ASN.1 PKCS#7 builder — no external PKCS#7 dependency. The CSR reader accepts both base64-encoded DER (standard EST wire format) and PEM-encoded PKCS#10 (convenience for debugging).
@@ -795,20 +792,17 @@ The SCEP (Simple Certificate Enrollment Protocol) server provides certificate en
 
 **Architecture:** SCEP follows the exact same layering as EST — a handler-level protocol that delegates certificate issuance to an existing `IssuerConnector`. The `SCEPService` bridges the `SCEPHandler` to whichever issuer connector is configured via `CERTCTL_SCEP_ISSUER_ID`.
 
-```
+```mermaid
-Client (MDM, network device, SCEP client)
+flowchart TD
-    │
+    Client["Client (MDM, network device, SCEP client)"]
-    ▼
+    Handler["SCEPHandler (handler layer)"]
-SCEPHandler (handler layer)
+    Service["SCEPService (service layer)"]
-    │  PKCS#7 envelope parsing, CSR extraction, challenge password extraction
+    Issuer["IssuerConnector (connector layer via IssuerConnectorAdapter)"]
-    ▼
+    Result["Signed certificate returned as PKCS#7 certs-only"]
-SCEPService (service layer)
+    Client --> Handler
-    │  Challenge password validation, CSR validation, CN/SAN extraction, audit recording
+    Handler -->|"PKCS#7 envelope parsing, CSR extraction, challenge password extraction"| Service
-    ▼
+    Service -->|"challenge password validation, CSR validation, CN/SAN extraction, audit recording"| Issuer
-IssuerConnector (connector layer via IssuerConnectorAdapter)
+    Issuer -->|"certificate signing (Local CA, step-ca, etc.)"| Result
-    │  Certificate signing (Local CA, step-ca, etc.)
-    ▼
-Signed certificate returned as PKCS#7 certs-only
 ```
 
 **Wire format:** Two paths, tried in order. The new RFC 8894 path (post-2026-04-29) parses the full PKIMessage shape: ContentInfo → SignedData → SignerInfo (POPO over auth-attrs verified via `internal/pkcs7/signedinfo.go::SignerInfo.VerifySignature` with the canonical SET-OF Attribute re-serialisation per RFC 5652 §5.4) → EnvelopedData (decrypted via `internal/pkcs7/envelopeddata.go::EnvelopedData.Decrypt` with RSA PKCS#1v1.5 keyTrans + AES-CBC content + constant-time PKCS#7 unpad to close the padding-oracle leak) → inner PKCS#10 CSR. Auth-attrs (messageType, transactionID, senderNonce) flow through to the service layer via `domain.SCEPRequestEnvelope`. The handler dispatches on messageType: PKCSReq (19) → initial enrollment; RenewalReq (17) → re-enrollment with chain validation; GetCertInitial (20) → polling stub returns FAILURE+badCertID. Responses are full CertRep PKIMessages (`internal/pkcs7/certrep.go::BuildCertRepPKIMessage`) signed by the per-profile RA cert/key with the issued cert chain encrypted to the device's transient signing cert (RFC 8894 §3.3.2). On parse failure the handler falls through to the legacy MVP path: base64-encoded PKCS#7 and raw CSR submissions are still accepted; responses use the legacy PKCS#7 certs-only shape via the shared `internal/pkcs7` package. The MVP fall-through is non-negotiable — backward compat with lightweight SCEP clients that don't speak full RFC 8894. Single certs are returned as raw DER for `GetCACert`, chains as PKCS#7.
@@ -890,23 +884,27 @@ each per-profile dispatcher carries its own **trust anchor pool**:
 the public certs the operator extracted from the Connector's
 installation. Every Intune-flavored enrollment goes through:
 
-```
+```mermaid
-                          ┌─────────────────────────────────┐
+flowchart TD
-                          │ Per-profile TrustAnchorHolder    │
+    TAH["Per-profile TrustAnchorHolder<br/>(RWMutex pool, SIGHUP-reloadable)"]
-                          │ (RWMutex pool, SIGHUP-reloadable) │
+    Device[device]
-                          └────────────┬────────────────────┘
+    Handler[handler]
-                                       │ Get()
+    Dispatch["SCEPService.dispatchIntuneChallenge"]
-                                       ▼
+    Validate["intune.ValidateChallenge<br/>(sig + iat/exp + audience)"]
-device → SCEP PKIMessage → handler → SCEPService.dispatchIntuneChallenge
+    Match["claim.DeviceMatchesCSR<br/>(set-equality)"]
-                                       │
+    Replay["intune.ReplayCache.CheckAndInsert"]
-                                       ├─► intune.ValidateChallenge (sig + iat/exp + audience)
+    Rate["intune.PerDeviceRateLimiter.Allow"]
-                                       ├─► claim.DeviceMatchesCSR (set-equality)
+    Compliance["(V3-Pro) ComplianceCheck hook"]
-                                       ├─► intune.ReplayCache.CheckAndInsert
+    Process["processEnrollment → IssuerConnector"]
-                                       ├─► intune.PerDeviceRateLimiter.Allow
+    Device -->|SCEP PKIMessage| Handler
-                                       └─► (V3-Pro) ComplianceCheck hook
+    Handler --> Dispatch
-                                       │
+    TAH -.->|Get()| Dispatch
-                                       ▼
+    Dispatch --> Validate
-                              processEnrollment → IssuerConnector
+    Dispatch --> Match
+    Dispatch --> Replay
+    Dispatch --> Rate
+    Dispatch --> Compliance
+    Dispatch --> Process
 ```
 
 The trust anchor file is mode-0600 on disk; certctl loads it at
@@ -932,22 +930,16 @@ See [`scep-intune.md`](scep-intune.md) for the full migration playbook
 
 The local issuer's CA private key is wrapped behind the `signer.Signer` interface in `internal/crypto/signer/`. Every CA-signing call site — leaf certificate issuance (`x509.CreateCertificate`), CRL generation (`x509.CreateRevocationList`), and OCSP response signing (`ocsp.CreateResponse`) — accesses the key through this interface rather than touching `crypto.Signer` directly. The interface embeds the stdlib `crypto.Signer` and adds a single `Algorithm() Algorithm` method so call sites can pick the matching `x509.SignatureAlgorithm` without reflecting on the concrete key type.
 
-```
+```mermaid
-                                          ┌─────────────────────────────────┐
+flowchart LR
-                                          │  signer.Driver (pluggable)      │
+    Local["internal/connector/issuer/local<br/>c.caSigner signer.Signer"]
-                                          ├─────────────────────────────────┤
+    subgraph Driver["signer.Driver (pluggable)"]
-internal/connector/issuer/local           │  signer.FileDriver  (default)   │
+        File["signer.FileDriver (default)<br/>PEM key on disk"]
-   c.caSigner signer.Signer  ──────────►  │    PEM key on disk              │
+        Memory["signer.MemoryDriver (tests)<br/>in-memory only"]
-                                          │                                 │
+        PKCS11["signer.PKCS11Driver (V3-Pro)<br/>HSM token (future)"]
-                                          │  signer.MemoryDriver  (tests)   │
+        Cloud["signer.CloudKMSDriver (V3-Pro)<br/>AWS / GCP / Azure (future)"]
-                                          │    in-memory only               │
+    end
-                                          │                                 │
+    Local --> Driver
-                                          │  signer.PKCS11Driver  (V3-Pro)  │
-                                          │    HSM token (future)           │
-                                          │                                 │
-                                          │  signer.CloudKMSDriver (V3-Pro) │
-                                          │    AWS / GCP / Azure (future)   │
-                                          └─────────────────────────────────┘
 ```
 
 Today only `FileDriver` (production) and `MemoryDriver` (tests) ship. The interface exists so PKCS#11/HSM and cloud-KMS drivers can land in follow-on packages (`internal/crypto/signer/pkcs11`, etc.) without modifying any call site or any other driver. The L-014 file-on-disk threat-model carve-out documented at the top of `internal/connector/issuer/local/local.go` applies to `FileDriver`-backed signers; alternative drivers that keep the key inside an HSM token or cloud KMS close the disk-exposure leg of the threat model entirely.

docs/ci-pipeline.md

@@ -17,17 +17,28 @@ This guide covers the **on-push pipeline** only.
 
 ## On-push pipeline (7 status checks)
 
-```
+```mermaid
-push to master
+flowchart TD
-  ├── CI workflow (5 jobs)
+    Push["push to master"]
-  │   ├── go-build-and-test       (~6-7 min)
+    CI["CI workflow (5 jobs)"]
-  │   ├── frontend-build          (~1 min)
+    CodeQL["CodeQL workflow (2 jobs)"]
-  │   ├── helm-lint               (~10 sec)
+    GoBuild["go-build-and-test<br/>~6-7 min"]
-  │   ├── deploy-vendor-e2e       (~5 min, depends on go-build-and-test)
+    Frontend["frontend-build<br/>~1 min"]
-  │   └── image-and-supply-chain  (~3 min, parallel)
+    HelmLint["helm-lint<br/>~10 sec"]
-  └── CodeQL workflow (2 jobs)
+    Vendor["deploy-vendor-e2e<br/>~5 min, depends on go-build-and-test"]
-      ├── Analyze (go)            (~5 min, parallel)
+    Image["image-and-supply-chain<br/>~3 min, parallel"]
-      └── Analyze (javascript-typescript)  (~5 min, parallel)
+    AnalyzeGo["Analyze (go)<br/>~5 min, parallel"]
+    AnalyzeJS["Analyze (javascript-typescript)<br/>~5 min, parallel"]
+    Push --> CI
+    Push --> CodeQL
+    CI --> GoBuild
+    CI --> Frontend
+    CI --> HelmLint
+    CI --> Vendor
+    CI --> Image
+    CodeQL --> AnalyzeGo
+    CodeQL --> AnalyzeJS
+    GoBuild -.depends on.-> Vendor
 ```
 
 End-to-end wall-clock: dominated by `go-build-and-test` + `deploy-vendor-e2e` chain (~12 min) running in parallel with CodeQL (~5 min). Target ~10 min.

docs/est.md

@@ -251,20 +251,16 @@ This recipe stands up an EAP-TLS-authenticated corporate WiFi network
 where certctl issues every device certificate via EST. End-to-end
 flow:
 
-```
+```mermaid
-┌─────────────┐      ┌──────────────────┐      ┌─────────────┐
+flowchart LR
-│ Laptop /    │ EAP  │ WiFi access      │ Radius│ FreeRADIUS  │
+    Laptop["Laptop / supplicant<br/>(wpa_supplicant / iwd / Apple WiFi)"]
-│ supplicant  │─────▶│ point (NAS)      │──────▶│ (validate   │
+    AP["WiFi access point (NAS)"]
-│ (wpa_       │      │                  │      │  cert chain)│
+    Radius["FreeRADIUS<br/>(validate cert chain)"]
-│  supplicant │      └──────────────────┘      └──────┬──────┘
+    CA["certctl CA<br/>(EST profile 'wifi')"]
-│  / iwd /    │                                       │
+    Laptop -->|EAP| AP
-│  Apple WiFi)│                                       │ trusts
+    AP -->|Radius| Radius
-└──────┬──────┘                                       ▼
+    Radius -.->|trusts| CA
-       │ EST (one-time, then renewal)         ┌─────────────┐
+    Laptop -->|"EST: /simpleenroll, /simplereenroll<br/>(one-time, then renewal)"| CA
-       │ /simpleenroll, /simplereenroll       │ certctl CA  │
-       └────────────────────────────────────▶│ (EST profile│
-                                              │  "wifi")    │
-                                              └─────────────┘
 ```
 
 ### certctl-side: EST profile config for 802.1X

docs/legacy-est-scep.md

@@ -37,12 +37,13 @@ straight at certctl on `:8443`.
 
 ## Architecture
 
-```
+```mermaid
-                          ┌─── TLS 1.2/1.3 ────┐         ┌─── TLS 1.3 ───┐
+flowchart LR
-[legacy EST/SCEP client]──>│ nginx / HAProxy   │────────>│ certctl :8443 │
+    Client["legacy EST/SCEP client"]
-                          │ reverse proxy      │         │               │
+    Proxy["nginx / HAProxy<br/>reverse proxy"]
-                          └────────────────────┘         └───────────────┘
+    Server["certctl :8443"]
-        Allowed TLS 1.2                  Re-encrypts as TLS 1.3
+    Client -->|"TLS 1.2/1.3<br/>(allowed TLS 1.2)"| Proxy
+    Proxy -->|"TLS 1.3<br/>(re-encrypts as TLS 1.3)"| Server
 ```
 
 The reverse proxy:

docs/qa-test-guide.md

@@ -38,22 +38,15 @@ either manual-only by design or pending QA-suite coverage:
 
 ## Architecture
 
-```
+```mermaid
-┌────────────────────────┐     ┌─────────────────────────────────┐
+flowchart LR
-│  qa_test.go            │────▶│  certctl demo stack             │
+    QA["qa_test.go (//go:build qa)<br/><br/>TestQA(t *testing.T)<br/>├─ Part01_Infra<br/>├─ Part02_Auth<br/>├─ Part03_CertCRUD<br/>├─ ...<br/>└─ Part52_HelmChart"]
-│  (//go:build qa)       │     │  docker-compose.yml +           │
+    subgraph Stack["certctl demo stack<br/>docker-compose.yml + docker-compose.demo.yml"]
-│                        │     │  docker-compose.demo.yml        │
+        Server["certctl-server :8443"]
-│  TestQA(t *testing.T)  │     │                                 │
+        Postgres["postgres :5432"]
-│   ├─ Part01_Infra      │     │  ┌─ certctl-server :8443        │
+        Agents["certctl-agent (×N)<br/>↑ seed_demo.sql provisions 12 agent rows<br/>(1 active, 2 retired, 9 reserved/sentinel)<br/>for the soft-retire / FSM coverage Parts 55–56 exercise"]
-│   ├─ Part02_Auth       │     │  ├─ postgres :5432              │
+    end
-│   ├─ Part03_CertCRUD   │     │  └─ certctl-agent (×N)          │
+    QA --> Stack
-│   ├─ ...               │     │      ↑ seed_demo.sql provisions │
-│   └─ Part52_HelmChart  │     │        12 agent rows (1 active, │
-└────────────────────────┘     │        2 retired, 9 reserved /  │
-                               │        sentinel) for the soft-  │
-                               │        retire / FSM coverage    │
-                               │        Parts 55–56 exercise.    │
-                               └─────────────────────────────────┘
 ```
 
 > **Multi-agent demo stack (Bundle Q / L-004 closure).** The demo

docs/scep-intune.md

@@ -36,21 +36,13 @@ What you get over NDES:
 
 ## Architecture
 
-```
+```mermaid
-┌──────────────┐       ┌──────────────────────┐       ┌──────────────┐
+flowchart LR
-│ Intune cloud │──────▶│ Intune Certificate   │──────▶│ certctl SCEP │
+    Cloud["Intune cloud<br/>(Microsoft)"]
-│              │       │ Connector            │       │ server       │
+    Connector["Intune Certificate Connector<br/>(customer infra)"]
-│ (Microsoft)  │       │ (customer infra)     │       │ (you)        │
+    Server["certctl SCEP server<br/>(you)"]
-└──────────────┘       └──────────────────────┘       └──────┬───────┘
+    Issuer["issuer connector<br/>(local CA / Vault / EJBCA / …)"]
-                                                              │
+    Cloud --> Connector --> Server --> Issuer
-                                                              ▼
-                                                       ┌──────────────┐
-                                                       │ issuer       │
-                                                       │ connector    │
-                                                       │ (local CA /  │
-                                                       │  Vault /     │
-                                                       │  EJBCA / …)  │
-                                                       └──────────────┘
 ```
 
 **certctl replaces NDES, not the Connector.** The Intune Certificate