Read the secrets-engine-openbao client secret in memory from OpenBao

Founder direction 2026-10-06 and ops-mason plan
keycape-secrets-engine-openbao-client-custody (658cdbc): no workstation copy.
service-jwt now gets CLIENT_SECRET from platform/workloads/keycape/
secrets-engine-openbao through one attended OIDC login on
keycape-secrets-engine-openbao-operator-workload-kv-read (-no-store, token from
a pipe, header-only GET, unconditional revoke-self). The consumer file is
refused for this profile and kept for the approval client.
service-auth probe-openbao prints value-free first-use evidence.

SECRETS-WP-0012: T02 cancelled (D1-D4 superseded), T04 done, T03 is the
founder-run first live use. Synthetic tests only; 524 passed, 1 skipped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 132360@bnt-lap001
Assistant-Session: 769b1afd-4330-4c86-96b2-e510e26db42b

docs/service-auth.md

@@ -12,17 +12,21 @@ the non-cryptographic contract before any future OpenBao login:
   and renewal when no more than three minutes remain;
 - no ID token, refresh token, implicit retry provider, or fallback identity.
 
-The confidential-client secret must be an explicitly selected mode-0600 file
-outside every Git worktree. It is sent with HTTP Basic authentication and never
-placed in a request body, command argument, evidence record, or object
-representation.
-
-Since 2026-10-06 the file must also be a canonical regular file (no symlink
-component) owned by the running user, in a parent directory owned by that
-user with mode 0700, and hold exactly one token.
-`secrets-engine service-auth check-secret-file [--path P] [--json]` reports
-those checks without the value. Consumer host, path, delivery and lifecycle
-coordinates: [keycape-openbao-consumer-custody.md](keycape-openbao-consumer-custody.md).
+Since 2026-10-06 (founder direction; ops-mason plan
+`keycape-secrets-engine-openbao-client-custody`) the `secrets-engine-openbao`
+client secret has **no consumer file**. Each command that selects
+`service-jwt` reads it in memory from OpenBao (`platform/workloads/keycape/secrets-engine-openbao`,
+field `CLIENT_SECRET`) through one attended `bao login -method=oidc -no-store`
+on role `keycape-secrets-engine-openbao-operator-workload-kv-read`, with the
+token captured from a pipe, used only in a request header, and revoked with
+`revoke-self` right after the read. Ambient `BAO_TOKEN`/`VAULT_TOKEN` and the
+token helper are never used, and `SECRETS_ENGINE_KEYCAPE_CLIENT_SECRET_FILE`
+is refused for this profile. The value is sent only with HTTP Basic
+authentication and never placed in a request body, command argument, env,
+file, evidence record, or object representation.
+`secrets-engine service-auth probe-openbao [--json]` runs the whole chain and
+prints value-free evidence. Coordinates, first-use command and lifecycle:
+[keycape-openbao-consumer-custody.md](keycape-openbao-consumer-custody.md).
 
 JWT payload parsing does not prove a signature. OpenBao must verify RS256
 against the configured issuer before issuing a token. railiance-platform owns
@@ -42,7 +46,8 @@ Canonical provider contract:
 ## Approval identity is separate
 
 [Approval service authentication](approval-service-auth.md) uses its own
-client-secret input, resource audience, exact tenant:platform and per-request
+client-secret file (`SECRETS_ENGINE_APPROVAL_CLIENT_SECRET_FILE`, checked by
+`service-auth check-secret-file`), resource audience, exact tenant:platform and per-request
 read/consume scopes. Never put that credential into the OpenBao provider.
 Both providers now validate KeyCape’s actual `level`/`methods` assurance shape;
 the old `aal`/`method` fixture was incompatible with the issuer.