Promote rein-openweights-openrouter-approle: draft -> active

Founder completed paste-once-provision; glas-harness/GLAS-WP-0002-T02's
live verification succeeded for real (AppRole login, KV v2 read, real
OpenRouter call, real commit, OPENROUTER_API_KEY unset throughout).

Two real fixes recorded along the way: platform-admin's policy needed
a new reins/* entry (every other KV mount was already listed there),
and the consumer policy itself needed the KV v2 data/+metadata/ path
shape instead of the bare KV v1 path it was originally written against.
Full account in ops-mason/plans/rein-openweights-openrouter-approle.md
section 7.

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

wiki/playbooks/rein-openweights-openrouter-approle.md

@@ -1,9 +1,9 @@
 # rein-openweights AppRole for non-interactive OpenRouter key read
 
-Date: 2026-07-27
-Catalog: `rein-openweights-openrouter-approle` (status `draft`, `resolvable: true` once the founder pastes the value)
+Date: 2026-07-27 (promoted to `active` same day, after live verification)
+Catalog: `rein-openweights-openrouter-approle` (status `active`, `resolvable: true`)
 Owner: `ops-mason` (`plans/rein-openweights-openrouter-approle.md`) · consumer: `rein-openweights`
-glas-harness: `GLAS-WP-0002-T02` (the demand this lane unblocks)
+glas-harness: `GLAS-WP-0002-T02` (the demand this lane unblocks — closed)
 
 An OpenRouter API key so `rein-openweights` (the OpenRouter-driven rein in the
 glas-harness family) can authenticate to OpenBao **non-interactively** — no
@@ -62,16 +62,28 @@ lane once the value is provisioned.
 
 ## Founder provision (the one place the live value exists outside OpenBao)
 
-Not yet done — this is what keeps this entry `status: draft`. Once ready:
+**Done (2026-07-27)** via `warden desk --act paste_once_provision --path
+reins/rein-openweights/openrouter --field api_key`. Two real issues hit
+along the way, both fixed at the root cause rather than patched around:
 
-```bash
-# Through ops-warden's paste-once-provision desk (localhost web form),
-# never a terminal/chat/git paste of the real key.
-```
+- `platform-admin`'s own policy had no entry for the new `reins/` mount
+  (every other KV mount was already listed there; this one predated the
+  fix) — the desk write 403'd until a matching `path "reins/*" {...}`
+  block was added.
+- The consumer policy itself (`workload-kv-read-rein-openweights-openrouter`)
+  was originally written against the bare KV path — the KV v1 shape,
+  which silently denies everything on a v2 mount. Fixed to grant on
+  `reins/data/rein-openweights/openrouter` +
+  `reins/metadata/rein-openweights/openrouter` instead (see
+  `ops-mason/plans/rein-openweights-openrouter-approle.md` §7 for the
+  full account, and `ops_mason/executor.py::_policy_hcl` for the code
+  fix + regression test).
 
-Then re-verify field presence (length only, never the value), promote this
-catalog entry to `active`, and notify `glas-harness`/`rein-openweights` so
-`GLAS-WP-0002-T02`'s live verification can proceed.
+Field verified present (length only, never the value) after the fix.
+`GLAS-WP-0002-T02`'s live verification then succeeded for real: AppRole
+login, KV v2 read, a real OpenRouter API call, a real commit —
+`OPENROUTER_API_KEY` unset throughout, so it was genuinely the vault path
+that ran.
 
 ## Rotation