Close T04 and pin the single route by which a principal becomes human

KEY-WP-0014-T04 sat `wait` with nothing outstanding, which is a contradiction.
Its title is admit rotation and verify consumer handoff, and both are delivered:
the semantics are published, the executor, authority and transport are named, the
CCR will be prepared on request, and step 4 shipped as keycape verify-client;
ops-warden took option (a) for the reason given, with both lanes owner-confirmed
and no route changed. Executing a rotation was never its deliverable, so treating
the owner's deferral as an open item would have kept the task open against work
it was not scoped to do. The deferral stands separately, revisited on evidence.

GH-DEC-2026-016 §5 applies A-16 to what makes a principal human. Verified against
source that `human` has exactly one route here -- a literal on the
authorization-code path after an upstream login resolved to a directory user,
with no configuration able to assert it -- so A-16 does not yet bite and no
provenance claim is warranted. Adding one would encode a distinction that does
not exist.

Asserting the behaviour would not protect that: a test checking a human token
says human passes just as happily when the value starts coming from a
registration. The guard parses the package and requires every principal_type
assignment to be a string literal, the set being exactly human and service. It
covers both shapes -- the browser path assigns into a map, the service path uses
a key-value pair in a map literal -- and checking only assignments found one of
two routes and passed, which the pinned literal set caught. Verified by mutation.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6

workplans/KEY-WP-0014-native-credential-lane-handoff.md

@@ -4,11 +4,11 @@ type: workplan
 title: "Review native login and client credential lane handoffs"
 domain: infotech
 repo: key-cape
-status: blocked
+status: finished
 owner: codex
 topic_slug: native-credential-lane-handoff
 created: "2026-09-05"
-updated: "2026-09-08"
+updated: "2026-09-10"
 state_hub_workstream_id: "0d003df3-f7d3-5063-8ca0-e1e33f7df74a"
 ---
 
@@ -95,7 +95,7 @@ a defect; fixed under WARDEN-WP-0038.
 
 ```task
 id: KEY-WP-0014-T04
-status: wait
+status: done
 priority: high
 state_hub_task_id: "e7632c71-9676-5837-a925-7f905e3015c5"
 ```
@@ -325,7 +325,38 @@ a consumer requiring proof of rotation, or a decision to prove rotation step 4
 before relying on it elsewhere. Any of those makes the answer different; a
 calendar date does not.
 
-T04 therefore stays `wait` with nothing outstanding from any counterparty. The
-authority is answered, the transport named, the CCR offered on request, and
-`verify-client` is ready for step 4 whenever a window is chosen. Nobody is waiting
-on KeyCape, and KeyCape is waiting on a decision that has now been taken.
+**Closed 2026-09-10.** The paragraph above left T04 `wait` with nothing
+outstanding, which is a contradiction: `wait` means waiting or blocked, and this
+was neither. Re-reading the task against its own title settles it — *admit
+rotation and verify consumer handoff* — and both halves are delivered:
+
+- **Rotation admitted.** The semantics were reviewed and published
+  (`docs/native-authentication.md`), the executor and authority are named
+  (platform operator, attended founder session, governed
+  `openbao-platform-admin-login` lane, `founder_required` attended OIDC via
+  `role=platform-admin`), the transport is admitted, and the CCR will be prepared
+  on request. Step 4 shipped here as `keycape verify-client`, treating an
+  identical predecessor as a failure because an unchanged secret is a rotation
+  that did not happen. Steps 1–3 are custody's and are deliberately not
+  automated by this repository.
+- **Consumer handoff verified.** ops-warden took option (a) for the reason we
+  gave rather than out of caution — the proxy yields an OpenBao token and
+  `keycape login` an issuer JWT, so they were never one thing to cut over
+  between. Lane `key-cape-oidc-login` is `owner-confirmed` with our boundary
+  written in verbatim, and `rapp-qonto-keycape-client` was narrowed to steps 1–2
+  rather than cleared. No route was changed.
+
+*Executing* a rotation was never this task's deliverable, and treating the
+owner's deferral as an open item would have kept a task open against work it was
+never scoped to do. The deferral stands on its own above, revisited on evidence.
+
+Two residuals are recorded rather than carried here, because they belong to
+whoever next opens a window: `real_predecessor_rotation_tested: false` and
+`observed_wall_clock_expiry: false`. `verify-client -previous-secret-env` is
+ready to close the first the moment a genuinely distinct predecessor exists.
+
+Also standing, from ops-warden and not to be lost: until WARDEN-WP-0038 lands,
+**treat a `warden plan` verdict on any need containing a write, rotate or
+provision act as unreliable** — it inherits the verdict of the lane that reads
+the same path, and `autonomous` is documented as the signal to proceed without
+the founder. That applies to this repository whenever it plans a rotation.