Classify 5 proxy lanes interim; hold 6 pending secrets-engine

Revised the classification axis after inspecting the entries: sorting by
subsystem was wrong. Nine of eleven lanes are a generic KV read with the
caller's own token, duplicating no owner procedure. Test is now
procedure-or-lifecycle vs generic read.

Interim now: rapp-qonto-keycape-client (key-cape), binky-company-email-imap
and binky-qonto-api (tenant-engine), railiance-backup-offsite-lane and
agent-harness-forgejo-deploy (re-establish procedures).

Held: the six thin-wrapper lanes are permanent only if secrets-engine exec
stays per-lane; asked whether it generalizes (msg 7d55d332).

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

workplans/WARDEN-WP-0030-delegation-register.md

@@ -120,8 +120,8 @@ delegation:
 
 Backfill all 24 entries. `exec_owner` lanes become `mode: native`.
 `ssh-cert-host-access` becomes `mode: permanent` (ops-warden's own lane). The
-eleven undelegated proxies get a **drafted** classification plus intended owner,
-flagged in the workplan for founder review rather than asserted as settled.
+eleven undelegated proxies are classified per the founder review below — five
+`interim` now, six held pending secrets-engine's answer.
 
 ### T03 — `warden route gaps` + conformance test
 
@@ -178,22 +178,56 @@ fleet-visible capability gap.
 - [ ] Founder has reviewed the interim/permanent classification of the eleven
 - [ ] Register delivered to the named owner repos
 
-## Open question for the founder
+## Classification of the eleven (founder review, 2026-08-11)
 
-The eleven undelegated proxies are: `openbao-api-key`, `key-cape-oidc-login`,
-`issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`,
-`openrouter-llm-connect`, `railiance-backup-offsite-lane`, `forgejo-admin-api-token`,
-`binky-company-email-imap`, `binky-qonto-api`, `rapp-qonto-keycape-client`,
-`agent-harness-forgejo-deploy`.
+### The test
+
+An initial draft sorted by *subsystem* (tenant lanes → tenant-engine, workload lanes →
+secrets-engine). Inspecting the entries showed that is the wrong axis. Nine of the
+eleven share one `auth_method` — "caller's own OpenBao token" (operator OIDC via
+key-cape, or a `workload-kv-read-*` policy) — and one `fetch_command` shape,
+`bao kv get -field=X <path>`. No owner procedure is duplicated there. Contrast
+`whynot-design-npm-publish`, which needs npm config and token injection into a specific
+tool; that is a *procedure*, which is why WP-0019 handed it to secrets-engine.
+
+**Test: owner-specific procedure or lifecycle → `interim`. Generic KV read →
+ops-warden's thin wrapper is arguably `permanent`.**
+
+### Interim — classify now (5)
+
+| Lane | `intended_owner` | `blocked_on` |
+| --- | --- | --- |
+| `rapp-qonto-keycape-client` | key-cape | `client_secret_basic` exchange is a key-cape protocol procedure, not a KV read; rotation already `automatable: true`, so key-cape could front it today |
+| `binky-company-email-imap` | tenant-engine | Custody at `tenants/binky/...` but rotation owner is `binky-control` — split lifecycle, no front door reconciling it |
+| `binky-qonto-api` | tenant-engine | Same split, same tenant |
+| `railiance-backup-offsite-lane` | railiance-platform | Rotation is `re-establish`, a multi-step procedure ops-warden only describes |
+| `agent-harness-forgejo-deploy` | railiance-platform / agent-harness | `re-establish` plus an alternative host-local key path; two ways in, neither owner-fronted |
+
+### Held pending secrets-engine (6)
+
+`openbao-api-key`, `key-cape-oidc-login`, `issue-core-ingestion-api-key`,
+`reuse-surface-hub-write-token`, `openrouter-llm-connect`, `forgejo-admin-api-token`.
+
+These pass the test as `permanent` **only if `secrets-engine exec` stays per-lane and
+provisioned.** If secrets-engine intends `exec --catalog <id>` to generalize over
+arbitrary OpenBao lanes, the thin-wrapper argument collapses and all six become
+`interim` with `intended_owner: secrets-engine` — ops-warden would then be duplicating
+a front door the owner provides.
+
+Asked directly (msg `7d55d332`, 2026-08-11): generic or per-lane; if generic, is it
+near-term enough to mark now; and are there lanes they would decline, so those can be
+marked permanent with the owner's position on record rather than ops-warden's inference.
+
+Supporting detail: for `issue-core-ingestion-api-key`, `reuse-surface-hub-write-token`
+and `openrouter-llm-connect`, **production never touches the proxy** — External Secrets
+syncs the value into the cluster and the proxy exists for operator verification and
+debugging. That weakens the case that they represent a missing front door at all.
+
+**Do not backfill these six until the answer arrives.** A lane wrongly marked
+`permanent` bakes in exactly the ownership drift this register exists to catch.
+
+### user-engine
 
-Draft reading, for review in T02: `key-cape-oidc-login` is **permanent** (login is
-key-cape's and the proxy is convenience, not custody). `openbao-api-key` is the
-generic escape hatch and is arguably permanent-by-design. The two `binky-*` tenant
-lanes and `rapp-qonto-keycape-client` look like **tenant-engine** gaps (WP-0028
-defined the custody pattern; no tenant front door executes it). The workload secret
-lanes — `issue-core-*`, `openrouter-llm-connect`, `reuse-surface-*`,
-`railiance-backup-*`, `forgejo-admin-*`, `agent-harness-forgejo-deploy` — look like
-**secrets-engine** gaps of the same shape WP-0019 already closed for npm publish.
 No lane names **user-engine** as owner — it appears only as a consumer inside
 `coulomb-social-runtime-env` (`USER_ENGINE_PROXY_SECRET`, rotated at
 `user-engine/user-engine-runtime`). Whether user-engine should front that lane itself