Admit KeyCape approval-engine client custody paths and delivery

Answers KEY-WP-0013-T02. Both proposed KV paths are confirmed unchanged; the
field name is corrected to CLIENT_SECRET for the platform uppercase convention
and the CCR validator. Kubernetes delivery references are confirmed against the
live sso namespace. Attended authority is the governed openbao-platform-admin-login
lane, and the rollout is one attended window ordered after the Authelia issuer
precondition.

Adds CCR-2026-0017/0018, two exact-path read policies, two namespace-limited
ClusterSecretStores with Kubernetes auth, two ExternalSecrets, and RPF-WP-0035-T05.
Nothing is applied and no value exists: both CCRs remain proposed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5

workplans/README.md

@@ -11,7 +11,7 @@ plans is not a count of missing implementations or independent incidents.
 | [RPF-WP-0029](RPF-WP-0029-backup-credential-default-removal.md) | Backup cutover and full offsite application recovery complete; old share invalidation receipt remains | S3 retains custody acceptance; S1 and forge own their backup execution. |
 | [RPF-WP-0025](RPF-WP-0025-openbao-operator-only-access.md) | Private OpenBao access; fresh attended callback/login then guarded retraction | Coordinate package, issuer, tunnel and DNS owners; keep the window separate. |
 | [RPF-WP-0015](RPF-WP-0015-audit-core-custody-and-recovery-coordination.md) | Two prepared recovery exercises; registered load driver exists; fresh sender/window/abort approvals and custody readiness remain | S3 contributes lease/ESO and snapshot/unseal proof; S1/S2 and audit-core execute their parts. |
-| [RPF-WP-0035](RPF-WP-0035-credential-lane-implementation.md) | Two remaining lanes: secrets-engine JWT and Fluid operator KV | Signing T04 is complete; JWT and Fluid retain separate issuer/consumer gates. |
+| [RPF-WP-0035](RPF-WP-0035-credential-lane-implementation.md) | Three remaining lanes: secrets-engine JWT, Fluid operator KV, KeyCape approval clients | Signing T04 is complete; T05 admission answered and awaiting owner approval plus a founder-attended window. |
 | [RPF-WP-0036](RPF-WP-0036-platform-service-assurance.md) | Implemented local assurance/admission; waits for recurring restore evidence, Q2 reception and owner handoff | Run the assurance commands; live acceptance and external ownership remain gated. |
 | [RPF-WP-0038](RPF-WP-0038-forgejo-scaleway-primary-coverage.md) | Native backup, full Scaleway archive recovery and 273 MiB Nextcloud essentials recovery verified; scheduled tier cutover remains | Bind recurring caller/dependencies, verified inventory, quota checks and separate owner retention. |
 

workplans/RPF-WP-0035-credential-lane-implementation.md

@@ -7,7 +7,7 @@ repo: railiance-platform
 status: blocked
 owner: codex
 created: "2026-09-05"
-updated: "2026-09-06"
+updated: "2026-09-08"
 related:
   - RPF-WP-0032
   - RPF-WP-0033
@@ -141,6 +141,51 @@ chart commit `49e3182`, Helm revision 59. No repository rename executed.
 Evidence: `docs/evidence/RPF-WP-0035-T04-signing-activation-2026-09-05.json`;
 closure: `history/2026-09-05-preflight-signing-activation-complete.md`.
 
+## Admit KeyCape approval-engine client custody and delivery
+
+```task
+id: RPF-WP-0035-T05
+status: wait
+priority: high
+```
+
+Answers KEY-WP-0013-T02 (State Hub message
+`278a3ebe-b529-49f6-bd1a-e3ebcf318260`). Admission:
+`docs/credential-lane-designs/keycape-approval-clients.md`; requests
+`CCR-2026-0017` (secrets-engine-approval) and `CCR-2026-0018`
+(approval-engine-operator).
+
+Platform owns the two custody paths, exact-path read policies, Kubernetes auth
+roles and the KeyCape-side ESO delivery. KeyCape owns the client registrations,
+issuance, claim set and disablement; approval-engine owns approval semantics and
+audit of emitted actions.
+
+2026-09-08 admission response: both proposed KV paths confirmed unchanged; field
+`client_secret` corrected to `CLIENT_SECRET` for the uppercase KV convention and
+CCR validator. Kubernetes delivery references confirmed against the live `sso`
+namespace, which already resolves `KEYCAPE_RAPP_QONTO_CLIENT_SECRET` through the
+same `secretKeyRef{key: client-secret}` shape on image `main-153258b`. Attended
+authority named as the governed `openbao-platform-admin-login` lane
+(`founder_required`); KeyCape's refusal to treat its generic `warden plan`
+database match as authorization was correct. Rollout agreed as one attended
+session with the KeyCape reading build pinned but undeployed, ordered after the
+Authelia issuer precondition in message `c8b1ad10-dae8-48fb-a0ea-7e2a101c54bf`.
+Policies, ClusterSecretStores and ExternalSecrets are written and validated,
+none applied.
+
+**Unblock:** owner approval of both CCRs, a KeyCape image that reads both
+environment names, the settled Authelia `iss` pin, and a founder-attended window
+date. Verifier-side custody only — no client-side read lane is admitted, and no
+scope beyond the two declared sets.
+
+**Done when:** both CCRs are approved, the attended window seeds both KV paths
+with CAS=0, policies/roles/stores/ExternalSecrets apply and sync, the KeyCape
+build resolves both environment names, KeyCape evidences live JWKS signature and
+exact claim bindings with excess scopes denied (operator `consume`, human
+`consume`), platform evidences cross-path/wrong-identity/out-of-namespace denial,
+and every receipt is metadata-only. If either registration is abandoned, KeyCape
+disables it before the KV version is destroyed.
+
 ## Dependency review — 2026-09-06
 
 SECRETS-WP-0008-T02 now records the local PIP claim/validation join implemented