Prepare the two approval client-side reader admissions

RPF-WP-0035-T06. Adds CCR-2026-0019 (secrets-engine) and CCR-2026-0020
(approval-engine-operator) with their exact-path read policies, reusing the
existing version-1 custody from the verifier activation. No reseed, rotation,
shared reader or verifier Secret reuse; both requests are in_flight and nothing
is applied.

The two shapes were decided by read-only survey rather than assumed.
secrets-engine consumes its client secret through an operator-run CLI reading a
protected file, and its namespace holds no workload, so reader 1 is an attended
operator-workstation OIDC lane rather than an ESO lane; its one missing input is
the operator group claim, which NetKingdom and KeyCape own. approval-engine is
not deployed and no owner source names who presents the operator client, so
reader 2 records the undetermined actor instead of guessing one for the widest
approval scope in the pair. Both declare openbao.auth missing rather than
carrying a placeholder binding.

T06 moves to wait on those two owner inputs.

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

openbao/policies/workload-kv-read-approval-engine-operator-client.hcl

@@ -0,0 +1,7 @@
+path "platform/data/workloads/approval-engine/operator-client" {
+  capabilities = ["read"]
+}
+
+path "platform/metadata/workloads/approval-engine/operator-client" {
+  capabilities = ["read"]
+}

openbao/policies/workload-kv-read-secrets-engine-approval-client.hcl

@@ -0,0 +1,7 @@
+path "platform/data/workloads/secrets-engine/approval-client" {
+  capabilities = ["read"]
+}
+
+path "platform/metadata/workloads/secrets-engine/approval-client" {
+  capabilities = ["read"]
+}