Record the answered rotation authority; T04 now waits on a decision

railiance-platform answered the question ops-warden routed for us: rotation steps
1-2 are the platform operator's, attended, through the governed
openbao-platform-admin-login lane under founder_required OIDC. No unattended
agent, and they named themselves in that exclusion.

What remains is an artifact and a decision, not an open question. There is no
rotation CCR and they will not raise one speculatively, rightly, since a
two-custodian CAS rotation with a service restart is a distinct version-guarded
operation. Their offer is to prepare it if KeyCape asks, and ops-warden
deliberately did not ask on our behalf. So the task waits on the repository owner
deciding whether the rotation should happen and when -- nothing indicates
compromise, so it is hygiene plus the first real exercise of rotation step 4,
which is a judgement call rather than an obvious yes.

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-0014-native-credential-lane-handoff.md

@@ -227,3 +227,55 @@ So `keycape verify-client`'s predecessor rejection has been exercised only
 against unit tests and a first provisioning where predecessor and successor were
 never distinct. Rotation step 4 is implemented and unproven, which is a different
 state from either "missing" or "done", and T04 is where that distinction lives.
+
+**2026-09-10: the authority is answered. What remains is an artifact and a
+decision.** railiance-platform answered the routed question (`7c7228ac`, relayed
+by ops-warden `b14655b3`):
+
+- **Who:** the platform operator, attended, as a founder-attended session. Not
+  ops-warden, not secrets-engine autonomously, and no unattended agent —
+  railiance-platform named themselves in that exclusion too.
+- **Transport:** the governed `openbao-platform-admin-login` lane, invoked only
+  through `warden access openbao-platform-admin-login --exec -- <command>` with a
+  unique metadata receipt path. The owner command is never run directly.
+- **Authority:** `founder_required` attended OIDC via netkingdom
+  `role=platform-admin`. Nothing else in that repo carries write authority
+  against `platform/workloads/`.
+
+**Missing: a rotation CCR.** They will not raise one speculatively, and their
+reason is sound — a two-custodian CAS rotation with a service restart is a
+distinct version-guarded operation, not an implementation detail of an existing
+lane. It must name the CAS precondition and expected version on *both*
+custodians, sibling-field preservation on the KV write, the restart window,
+bounded predecessor retention for rollback and denial checks, and the
+reconcile-to-same-version step on failure. That last is step 5 of the sequence in
+`docs/native-authentication.md`, so the reviewed sequence is what the CCR encodes.
+
+**Blocked on a decision that is not KeyCape's to take unilaterally.** Their offer:
+"if key-cape wants the rotation scheduled, say so and I will prepare it under
+RPF-WP-0035 with both custodians in one window." ops-warden deliberately did not
+ask on our behalf — correctly, per their ADR-0003, since implying an owner request
+from a routing errand is quiet ownership. So T04 now waits on the repository owner
+deciding whether the Qonto rotation should happen, and when. Nothing indicates
+compromise; this is hygiene plus the first real exercise of rotation step 4, which
+is why it is a judgement call rather than an obvious yes.
+
+**Precedent offered, and it is the right one.** The identical two-custodian shape
+was exercised 2026-09-09 for the approval clients: attended founder session,
+OpenBao KV custody plus a Kubernetes-delivered consumer copy, compatible pinned
+rollout, protected recovery retained, and rollback that restored configuration and
+image and detached delivery before a clean resume. Their
+`scripts/keycape_approval_custody.py` (activate / resume-activate / verify) is the
+shape a rapp-qonto rotation should follow rather than a bare `bao kv patch` — for
+exactly the provider/consumer consistency reason this task gave when it declined
+to ship a wrapper around a raw KV write. They endorsed that refusal unprompted.
+
+**And the `warden plan` defect is fixed** (WARDEN-WP-0038, 2026-09-10). The Qonto
+need now returns `founder_required` naming the write owner, and read transports
+are no longer offered against a write need. ops-warden's closing line is worth
+keeping: "Your caution was load-bearing and it should not have had to be."
+
+If the rotation is scheduled, it is also the first opportunity to close the
+`real_predecessor_rotation_tested: false` gap recorded above — `verify-client`
+with `-previous-secret-env` is exactly step 4, and the predecessor would finally
+be genuinely distinct.