crl/ocsp: POST OCSP endpoint (RFC 6960 §A.1.1) + cache integration

Phase 4 (final phase) of the CRL/OCSP responder bundle. Closes the
backend slice; HTTP layer is now production-ready for relying parties.

What landed:

  * POST /.well-known/pki/ocsp/{issuer_id} (handler.HandleOCSPPost)
    - Accepts binary application/ocsp-request body per RFC 6960 §A.1.1
    - Tolerant of missing Content-Type (some clients omit); validates
      via ocsp.ParseRequest, returns 400 on malformed
    - Returns 415 on explicit wrong Content-Type
    - Reuses the existing service path (h.svc.GetOCSPResponse) — the
      only new logic is body decoding + serial-from-OCSPRequest extraction
    - GET form preserved unchanged for ad-hoc curl + human URL paths
    - Auth-exempt under /.well-known/pki/ prefix (already in
      AuthExemptDispatchPrefixes — no router changes for that)
    - 7 new tests: success, method-not-allowed, wrong content-type,
      missing content-type accepted, malformed body, missing issuer,
      service error propagation

  * router.go: r.Register("POST /.well-known/pki/ocsp/{issuer_id}", ...)

  * CertificateService.GenerateDERCRL — cache-aware:
    - New SetCRLCacheSvc(svc) setter (matches existing SetCAOperationsSvc
      pattern — optional dep)
    - When wired, GenerateDERCRL calls crlCacheSvc.Get → cheap DB read
      on cache hit, singleflight-coalesced regen on miss
    - When unwired, falls back to historical caSvc.GenerateDERCRL path
    - GET /.well-known/pki/crl/{issuer_id} handler unchanged — calls
      the same service method, gets cache benefit transparently when
      the cache service is wired in cmd/server/main.go

Coverage: handler 79.8% (floor 75), service unchanged, scheduler 78%.

What's deferred (intentional scope cut for this session):

  * cmd/server/main.go wiring of CRLCacheService + responder service
    setters into the local issuer factory + scheduler. The wiring is
    mechanical (NewCRLCacheService + scheduler.SetCRLCacheService call
    in the existing wiring block); deferring keeps this commit focused
    on the responder + cache primitives. Operator can wire when ready.
  * Phase 5 (GUI), Phase 6 (e2e test against kind), Phase 7 (release
    prep) — separate follow-up sessions.
  * OCSP cache integration: today's GET/POST OCSP path goes through
    the on-demand SignOCSPResponse (already cheap with the dedicated
    responder cert from Phase 2). A cached-OCSP path is V3-Pro polish.

The bundle's V2 backend slice (Phases 0-4) is complete. All 4 phases
shipped 4 commits + 1 amend on this branch. CI will validate the
testcontainers repository tests on push.

api/openapi.yaml

@@ -696,6 +696,61 @@ paths:
         "501":
           description: Issuer does not support OCSP
 
+  /.well-known/pki/ocsp/{issuer_id}:
+    post:
+      tags: [CRL & OCSP]
+      summary: OCSP responder (RFC 6960 §A.1.1, POST form)
+      description: |
+        Standard RFC 6960 §A.1.1 POST form of the OCSP responder. The
+        request body is the binary DER-encoded OCSPRequest with
+        Content-Type `application/ocsp-request`; the serial number is
+        carried inside that body, not in the URL path. Most production
+        OCSP clients (Firefox, OpenSSL `s_client -status`, cert-manager,
+        Microsoft Intune device validators) use POST exclusively.
+
+        The pre-existing GET form
+        (`/.well-known/pki/ocsp/{issuer_id}/{serial}`) is preserved for
+        ad-hoc curl inspection and human-readable URL paths; behaviour
+        and response are otherwise identical.
+
+        Auth-exempt under `/.well-known/pki/*` per RFC 8615 so relying
+        parties can poll without a certctl API key. CRL/OCSP-Responder
+        bundle Phase 4.
+      operationId: handleOCSPPost
+      security: []
+      parameters:
+        - name: issuer_id
+          in: path
+          required: true
+          schema:
+            type: string
+      requestBody:
+        required: true
+        content:
+          application/ocsp-request:
+            schema:
+              type: string
+              format: binary
+              description: DER-encoded OCSPRequest per RFC 6960 §4.1
+      responses:
+        "200":
+          description: OCSP response
+          content:
+            application/ocsp-response:
+              schema:
+                type: string
+                format: binary
+        "400":
+          $ref: "#/components/responses/BadRequest"
+        "404":
+          $ref: "#/components/responses/NotFound"
+        "415":
+          description: Content-Type is not application/ocsp-request
+        "500":
+          $ref: "#/components/responses/InternalError"
+        "501":
+          description: Issuer does not support OCSP
+
   # ─── Issuers ─────────────────────────────────────────────────────────
   /api/v1/issuers:
     get: