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>

registry/routing/catalog.yaml

@@ -544,16 +544,23 @@ entries:
     wiki_ref: wiki/playbooks/rein-openweights-openrouter-approle.md#worker-checklist
     canon_ref: ops-mason/plans/rein-openweights-openrouter-approle.md
     reviewed: "2026-07-27"
-    status: draft
+    status: active
     risk: standard
     # Built 2026-07-27 by ops-mason (MASON-WP-0001-T05), approved by Bernd
     # Worsch 2026-07-27. Policy + AppRole live; reins/ KV v2 mount created
     # (no existing mount fit without widening scope beyond what was
     # approved). token_num_uses corrected from OpenBao's own default (0 =
-    # unlimited) to 8, matching agent-harness-binky-mail, after the live
-    # config was checked post-build. Status stays draft until the founder
-    # completes paste-once-provision and GLAS-WP-0002-T02's live
-    # verification succeeds -- then promote to active.
+    # unlimited) to 8, matching agent-harness-binky-mail. Policy path shape
+    # also corrected post-build: originally written against the bare KV
+    # path (KV v1 shape), which silently denies everything on a v2 mount --
+    # fixed to grant on <mount>/data/<path> + <mount>/metadata/<path>.
+    # platform-admin's own policy also needed a new "reins/*" entry before
+    # the founder's paste-once-provision could write the value (every
+    # other KV mount was already listed there; this one predated the fix).
+    # Promoted draft -> active: founder completed paste-once-provision and
+    # glas-harness/GLAS-WP-0002-T02's live verification succeeded --
+    # real AppRole login, real KV v2 read, real OpenRouter call, real
+    # commit, with OPENROUTER_API_KEY unset throughout.
     auth_method: "AppRole login role=rein-openweights (role_id+secret_id via REIN_OPENWEIGHTS_APPROLE_DIR)"
     path_template: "reins/rein-openweights/openrouter"
     fetch_command: "bao write -field=token auth/approle/login role_id=$ROLE_ID secret_id=$SECRET_ID  # then bao kv get -field=api_key reins/rein-openweights/openrouter"

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