Declare the security layer, and repair the placement admission check

Layer declaration (gate-house). INTENT.md now carries the declaration in its own
voice with layer.yaml as the machine-readable form, adapted from ops-warden's
reference. railiance-platform is Staff: operating OpenBao is not a claim to the
Tooling layer, because §4 is explicit that no operator-of-third-party-Tooling
shape exists and that someone running it stays a declared gap. Six direct
Tooling contacts are mapped by capability rather than by file — one §5.2
conduit, one §5.1 diagnostic, four §5.3 gaps with intended owners and review
dates — and the uncatalogued contacts are listed so the check is total. We are
PEP-shaped and the unreachable-engine stance map is NOT published; that is
recorded as an open obligation to build against v0.8, not left silent.

Placement admission. canned-prompts was added as a PostgresConsumer on
platform-pg-2 in rapp-postgres 1b68b4c without a placement owner here, which is
exactly the cross-repo drift the assurance check exists to catch; the check had
been failing on it. Registered with its real boundary evidence, corrected the
stale test expectation that pinned the overflow cell at one consumer, and
updated the SCOPE occupancy line to 2/4.

Also records owner input received today: key-cape's issuer view on CCR-2026-0020's
presenting actor, and their confirmation that codex-railiance-platform correctly
stays tenant:coulomb, so the flagged T02 discrepancy is closed as not-a-defect.

The whynot-design npm field is NOT changed. Two dated live receipts here name
NPM_AUTH_TOKEN as the field, including an attended founder fetch; that is
recorded against the counterparty claim rather than either side being flipped
before the session settles it.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5

docs/openbao-open-questions-session.md

@@ -14,7 +14,7 @@ establish, and each has been answered so far with "I will not guess":
 | Question | Thread | What is undecidable from repo source |
 | --- | --- | --- |
 | Q1 | secrets-engine `546403e4` | Whether the legacy path `secret/coulomb/whynot-design/npm/publish` still exists and holds a real token |
-| Q2 | secrets-engine `546403e4` | Which field backs the authoritative npm lane. My CCR says `NPM_AUTH_TOKEN`; secrets-engine says `npm_token`. Field names are not visible in KV v2 metadata |
+| Q2 | secrets-engine `546403e4`, ops-warden `b6212006` | Which field backs the authoritative npm lane. Two dated live receipts here name `NPM_AUTH_TOKEN`; secrets-engine says `npm_token` and ops-warden has already changed their catalog to it. Both can be true if the path carries both fields. Field names are not visible in KV v2 metadata |
 | Q3 | internal | The 2026-09-09 activation receipt records `policy_applied: false` for both KeyCape approval lanes while `role_applied: true`. Reads verified, so the policies must exist — but existence and repo agreement were never confirmed |
 | Q4 | CCR-2026-0019 | Which netkingdom OIDC roles and bound group claims already exist, as input to the operator group claim that lane is missing |
 | Q5 | risk-nexus `ee702ac9` | Which fields the governed backup lane actually carries, as RPF-WP-0029-T02 context |
@@ -62,12 +62,17 @@ the constraint risk-nexus set.
 
 ## What each answer unblocks
 
-- **Q1 + Q2 → secrets-engine.** A pointer plus a field name closes their custody
-  question. If Q2 returns `npm_token`, my CCR-2026-0001 is wrong about the field
-  and I correct it; if it returns `NPM_AUTH_TOKEN`, their catalog entry is the one
-  that moves, as a reviewed lane change carrying its own approval. If Q1 finds a
-  populated legacy path, that is a stale duplicate holding a real token and
-  becomes its own disposition item — do not delete it inside this session.
+- **Q1 + Q2 → secrets-engine and ops-warden.** Q2 is now the more urgent of the
+  two. ops-warden changed their catalog and playbook from `NPM_AUTH_TOKEN` to
+  `npm_token` on secrets-engine's statement, while this repository holds two dated
+  live receipts — including an attended founder fetch that exited zero — naming
+  `NPM_AUTH_TOKEN` as the field. If those receipts are right, that change points
+  the front door at a field that does not exist and the lane breaks on next use.
+  Q2 enumerates the real field names: `npm_token` only, `NPM_AUTH_TOKEN` only, or
+  both, and each outcome names exactly one side that has to move, as a reviewed
+  lane change carrying its own approval. If Q1 finds a populated legacy path, that
+  is a stale duplicate holding a real token and becomes its own disposition item —
+  do not delete it inside this session.
 - **Q3 → internal.** Either the policies match the repo, and the activation's
   `policy_applied: false` meant "no change needed", or they drift and that is a
   finding to fix under RPF-WP-0035 before anyone treats the verifier lanes as

docs/workload-kv-access-lanes.md

@@ -64,6 +64,20 @@ caller-scoped lane. The sibling lanes `issue-core-ingestion-api-key` and
 `openrouter-llm-connect` remain draft and are tracked separately by
 `RAILIANCE-WP-0009` and `RAILIANCE-WP-0010`.
 
+> **Field name contested, 2026-09-09 — do not change this on either side yet.**
+> secrets-engine states the KV field is `npm_token` and that `NPM_AUTH_TOKEN` is
+> only the environment variable their publication-scope policy injects;
+> ops-warden has already corrected their catalog and playbook on that statement.
+> This repository holds two dated live receipts naming `NPM_AUTH_TOKEN` as the
+> OpenBao **field**, in `CCR-2026-0001`: a field-presence check on
+> 2026-06-28T10:37:42Z, and an attended fetch by the founder on
+> 2026-06-28T15:22:29Z that exited successfully with output to `/dev/null` — a
+> `-field=` fetch that exits zero means that field exists. Both records can be
+> true if the path carries **both** fields. Q2 of the attended session
+> (`docs/openbao-open-questions-session.md`) enumerates the actual field names
+> and settles it. Until then this table stays as written, because it is the side
+> backed by receipts.
+
 The fetch command returns the secret value to the authenticated caller. Run it
 only in an attended shell or through a process that consumes the value without
 logging it.