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

credential-change-requests/CCR-2026-0020-approval-engine-operator-client-read.yaml

@@ -48,6 +48,22 @@ review:
       reader therefore cannot be named here without an owner decision, and
       naming one anyway would hand the widest approval scope to a guessed
       identity. Held in_flight deliberately.
+  - at: '2026-09-09'
+    reviewer: key-cape (issuer view, not a decision)
+    decision: presenting_actor_shapes_offered
+    comment: >-
+      KeyCape notes the registration carries both approval:create and
+      approval:approve, so a single presenter can create an entry and then
+      approve it. That is a separation-of-duties property of whoever holds the
+      credential, not a defect in the token: KeyCape issues exactly the grants
+      approval-engine requested. Two shapes are supportable -- two registrations
+      with disjoint create and approve grants, enforced at issuance and
+      available today; or one registration with the holder constrained by
+      custody, which is where it sits now. Which is right is approval-engine's
+      call and the doctrine question is gate-house's. Recorded in key-cape
+      docs/approval-engine-provisioning-request.yaml under
+      presenting_actor_note. This does not name an actor and does not unblock
+      this request.
 target:
   domain: financials
   tenant: platform