Close the KEY-WP-0009 handoff gap and deliver the two blocked admissions

KEY-WP-0009-T04 is done. Re-ran verification on main with an explicit Go 1.23.0
toolchain and a writable build cache: contract validator PASS, build, vet and the
full test suite pass, git diff --check clean. gofmt had drifted on
internal/server/telemetry/events.go and tests/migration/scenario_c_test.go
(comment alignment only, no semantic change); both reformatted so the task's
formatting claim holds. The four handoffs to netkingdom, secrets-engine,
ops-warden and railiance-platform were then actually sent -- the 2026-09-05 audit
had shown the earlier claimed delivery had no receipts -- and each receipt id is
recorded in the workplan and readable back from the hub.

KEY-WP-0013-T02 and KEY-WP-0014-T04 stay in wait. Their remaining work is not
ours to do, so what was owed was the request, and it is now delivered: custody
admission for the two approval clients to railiance-platform, the exact human
client id and callback URI to approval-engine, and the OpenBao-token vs
issuer-JWT split plus Qonto rotation execution authority to ops-warden. Each
message quotes the existing non-secret packet or reviewed sequence and states
what is explicitly not being treated as authorization.

No secret was read, no production resource changed, no route retired.
SCOPE.md updated to match.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad

workplans/KEY-WP-0013-approval-engine-resource-audience.md

@@ -8,7 +8,7 @@ status: blocked
 owner: codex
 topic_slug: approval-engine-resource-audience
 created: "2026-09-05"
-updated: "2026-09-06"
+updated: "2026-09-08"
 state_hub_workstream_id: "6e815d88-b0e3-5ce0-be5d-13ab15917f7f"
 ---
 
@@ -57,6 +57,34 @@ returned founder_required but matched an unrelated generic database lane; that
 mismatch is not authority to provision. Human callback clarification is pending.
 No secrets were read or production resources changed.
 
+2026-09-08: the two blocking requests were sent and their receipts are readable
+back via `GET /messages/?from_agent=key-cape`.
+
+- `278a3ebe-b529-49f6-bd1a-e3ebcf318260` -> railiance-platform. Custody admission
+  for both clients, quoting `docs/approval-engine-provisioning-request.yaml`
+  verbatim: exact OpenBao paths and `client_secret` field, the two Kubernetes
+  delivery references, the two `KEYCAPE_*_CLIENT_SECRET` environment names,
+  `tenant:platform` per decision `5ed3fb35-eca9-413a-82b9-95171ba85bf6`, and the
+  15m lifetime. It asks for four things explicitly: confirm/correct the paths and
+  fields, confirm the delivery references, name the authority for the attended
+  first provision, and agree a rollout window in which registrations and the
+  KeyCape version that reads them deploy together. It restates that the
+  `warden plan` `founder_required` result matched an unrelated generic database
+  lane and is not being treated as authorization.
+- `43fbd997-6e22-4859-8433-58b784c2df6c` -> approval-engine. Requests the two
+  missing human-registration inputs — the exact `client_id` and the full callback
+  URI — noting redirects are matched exactly and a near-miss fails closed at
+  `/authorize`. Restates the human client shape (public, S256 PKCE,
+  `audience: approval-engine`, `allowedScopes: [openid, approval:approve]`,
+  `mfaRequired: true`, no consume grant) and asks approval-engine to confirm it
+  validates the access token, not the ID token, against the deployed `/jwks`.
+
+Deployment state is unchanged from the 2026-09-05 observation: neither approval
+client is materialized. Task remains `wait` — the two admissions are owned by
+railiance-platform and approval-engine respectively, and live provisioning proof
+cannot begin until both land. Still no secret read and no production resource
+changed.
+
 ## Reconcile tenant vocabularies across approval layers
 
 ```task