Park the warden-sign AppRole with explicit un-park triggers

Founder decision 2026-08-11: neither withdraw nor proceed. The broker covers
the workstation, but unattended signing on a remote tunnel host is unresolved,
and there the AppRole is narrower than placing the broker's issuer token.

Recorded where each trigger will be hit: WP-0027 break-glass task (trust-root
design), and the ops-bridge cutover playbook (token source must be resolved
before going live). secrets-engine told to stop holding apply readiness.

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

workplans/ADHOC-2026-08-11.md

@@ -70,7 +70,7 @@ read. Inbox is now empty.
 - [x] **secrets-engine warden-sign** (`80456912`) — see T03; replied with status and
       referred the live-apply question to the owner.
 
-### T03 — Open question for the operator: withdraw or keep the warden-sign AppRole
+### T03 — warden-sign AppRole: PARKED pending WP-0027 break-glass + ops-bridge cutover
 
 ```task
 id: ADHOC-2026-08-11-T03
@@ -91,9 +91,38 @@ need is served by the railiance-platform credential broker
 (`ops-warden-warden-sign-token`, active; `credential.py exec --grant ops-warden/warden-sign`,
 proven via `make credential-exec-ops-warden-smoke`) — no AppRole involved.
 
-Decision needed from Bernd: keep the AppRole as a broker-independent fallback path to
-signing, or withdraw SECRETS-WP-0004. ops-warden's recommendation is **withdraw** unless
-there is a concrete failure mode the broker cannot cover — a second standing credential
-to rotate and audit is a real cost for a lane that currently works. Not ops-warden's call;
-asked secrets-engine to hold live apply until it resolves. Task stays `wait` pending that
-answer.
+**Resolved 2026-08-11: parked** — neither withdrawn nor proceeding. Founder decision
+after reviewing the mechanics. Communicated to secrets-engine (msg `863c7b57`) with an
+explicit instruction to stop holding apply readiness.
+
+An initial recommendation to **withdraw** was revised on inspection:
+
+- `warden sign` reads `VAULT_TOKEN` from the environment and has no AppRole login path
+  (`src/warden/vault.py:24-27`). The AppRole is a way for a *host* to obtain a token,
+  not an ops-warden code path — withdrawing costs no code and removes no working
+  capability. For the workstation, the broker plus attended operator OIDC is sufficient.
+- The uncovered case is **unattended signing on a remote host** — the pending ops-bridge
+  cert_command cutover. `wiki/playbooks/ops-bridge-tunnel-cert.md:61` still falls back to
+  a manually exported `VAULT_TOKEN` there.
+- Running the broker on that host means placing the railiance-platform checkout *and its
+  issuer token* (`credential-broker-warden-sign-issuer` — authority to mint warden-sign
+  tokens repeatedly) on it. The AppRole exchanges for a `warden-sign`-only token
+  (`update` on `ssh/sign/{agt,adm,atm}-role`). Both are standing credentials on a remote
+  host; **the AppRole is the narrower one**, and is the established NetKingdom pattern
+  for this shape (`rein-openweights-openrouter-approle`,
+  `agent-harness-binky-mail-approle`).
+
+No circular dependency exists today: OpenBao is a public endpoint
+(`https://bao.coulomb.social`), so obtaining a cert never requires already holding one.
+
+**Un-park triggers** (either one re-opens the question):
+
+1. **WARDEN-WP-0027** (backlog) designs the graded lockdown / break-glass path and its
+   explicit trust-root — a second autonomous path to signing is an input to that design,
+   not an isolated decision.
+2. **ops-bridge cert_command live cutover** reaches unattended signing on a remote host.
+
+Cheap to reverse: the secrets-engine dry-run plan is validated, re-runnable, and correct
+as drafted. The two operator gates (SECRETS-WP-0004 decision, mode-0600 lane bootstrap
+token) are deliberately *not* being satisfied while parked. Task stays `wait` until a
+trigger fires.