Declare layer machine-readably (§11); adopt v0.6 corrections

The standard moved v0.4 -> v0.6. All four findings from our v0.4 review
were adopted in v0.5, and v0.6 went further on two of them.

§11 now requires a machine-readable declaration — prose cannot
distinguish a declaration from a transcribed review. We had none.
Added layer.yaml (form adapted from ops-warden's reference
implementation), scripts/check_layer_conformance.py, and
tests/test_layer_conformance.py.

The check makes our central claim mechanical rather than asserted: no
direct Tooling client in src/. The test exercises the negative case on a
synthetic tree, so it fails if the checker goes blind. pyyaml is added as
a DEV dependency only — `dependencies = []` is load-bearing for the §5
claim and stays empty.

Adopted from v0.6:
- containment is no longer ours (§9.2). Actuation is an Engine concept,
  unowned and held at zero; kings-guard proposes containment and never
  performs it. The register row is now a dependency, not our gap.
- observation is scoped to Staff-reachable sources, with identity and
  secret observation pending — our finding 1, adopted near-verbatim.
- access-engine DECLINED the authentication-evidence gap; owner is now
  the identity layer plus audit-core, reproposed and unassented.
- §11 blocked-clean recorded, with the rule that it must not rank below
  conforming — our finding 2.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014379@bnt-lap001
Assistant-Session: 4af9e20f-1768-4afc-951b-b507784e382b

INTENT.md

@@ -1,35 +1,45 @@
 # INTENT
 
 > **Layer: Staff.** *(NetKingdom Security Layer Model — current version
-> `net-kingdom/canon/standards/security-layer-model_v0.4.md`, §4 catalog,
-> status accepted; ratified by `gate-house/decisions/decisions.md`
-> GH-DEC-2026-001; assented here by `decisions/decisions.md` KG-DEC-2026-001
-> on 2026-08-28, against v0.1. This declaration is made in kings-guard's own
-> voice, per §11.)*
+> `net-kingdom/canon/standards/security-layer-model_v0.6.md`, §4 catalog;
+> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001; assented here
+> by `decisions/decisions.md` KG-DEC-2026-001 on 2026-08-28, against v0.1.)*
 >
-> **Catalog entry (v0.4 §4):** adaptive defence, observation; **containment —
-> pending (§9.2)**, until an engine exposes a containment surface. The pending
-> mark exists because kings-guard raised the defect that v0.1 catalogued a
-> capability §5 forbade discharging; the general rule is now §9.1.
+> **The machine-readable declaration required by §11 is `layer.yaml`**, checked
+> by `scripts/check_layer_conformance.py` and tested in
+> `tests/test_layer_conformance.py`. Prose cannot distinguish a declaration from
+> a transcribed review, so the file is authoritative and this note is commentary.
 >
-> kings-guard is **interactive and non-deterministic**: adaptive defence,
-> observation, containment. Acting at runtime does not make a repository an
-> Engine; being agentic makes it Staff.
+> **Catalog entry (v0.6 §4):** adaptive defence and judgment; observation of
+> Staff-reachable sources — identity and secret observation **pending**;
+> **proposes** containment, which it does not own.
+>
+> kings-guard is **interactive and non-deterministic**. Acting at runtime does
+> not make a repository an Engine; being agentic makes it Staff.
 >
 > **The binding rule (§5): Staff never touches Tooling directly. It acts only
 > through Engine APIs.** kings-guard holds no direct client for a Tooling-layer
-> system — no database connection, no OpenBao client, no cluster mutation. It
-> may contain a threat only by calling an engine. Where no engine exposes a
-> capability kings-guard needs, that is raised as an **engine gap**, never
-> solved locally; the open gaps are listed under *System boundary* below.
+> system — no database connection, no OpenBao client, no cluster mutation, and
+> no §5.1 diagnostic read or §5.2 conduit either. Under §11 that is
+> **blocked-clean**: the capabilities needing such a contact sit at zero rather
+> than being taken locally, and §11 rules that this MUST NOT rank below
+> conforming.
+>
+> **Containment is not ours (§9.2).** v0.6 moved it off this repository
+> entirely: reduce authority, require step-up, and isolate a workload are
+> authority-changing operations, so they are rendered by an Engine and enforced
+> by a PEP. **kings-guard proposes containment; it never performs it.** The
+> actuation surface is unowned and held at zero estate-wide, so no argument
+> anywhere may assume containment is automatic.
 >
 > **Posture contract.** kings-guard **publishes** posture; `gate-house` defines
 > its authority meaning; `access-engine` renders it. Posture is not a privilege
 > source. The asymmetry is absolute: kings-guard may **reduce** authority,
 > **require step-up**, or **request containment**; it MUST NOT probabilistically
-> manufacture additional authority. Every effector request it emits therefore
-> carries an explicit authority boundary and is advisory unless the owning
-> system has already delegated a narrow, deterministic action lane.
+> manufacture additional authority. Every effector request carries an explicit
+> authority boundary. Under incomplete observation this asymmetry is what bounds
+> the damage: a suppressed event can only cost a tightening that should have
+> happened, never manufacture authority through us (§8, §9.6).
 
 > This file captures **why this repository exists**, the **direction it is
 > moving toward**, and the **kind of system it is meant to become**.
@@ -151,16 +161,18 @@ rule these are gaps to close in the owning engine, not work to route around.
 None is a standing licence to reach into Tooling.
 
 These are **unowned capabilities**, not §5.3 declared contacts: kings-guard
-makes no direct Tooling contact for any of them. Under §11 kings-guard is
-**Conforming**, not a tracked non-conformance. The fields follow §5.3's shape so
-one register can hold both, but the distinction is load-bearing — see the
-assessment sent to gate-house on 2026-08-29.
+makes no direct Tooling contact for any of them. v0.5 §11 added the
+**blocked-clean** state for exactly this case, on kings-guard's finding, and
+ruled that it MUST NOT rank below conforming.
+
+`layer.yaml` is the authoritative machine-readable form; this table is the
+human-readable view of it.
 
 | `capability` | Needed for | `intended_owner` | `blocked_on` | `review` |
 | --- | --- | --- | --- | --- |
-| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | `user-engine` / `access-engine` | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
+| Authentication and assurance evidence (token assurance, attestation outcomes, authentication anomalies) exposed as an engine surface | identity-drift posture | identity layer + `audit-core` — **`access-engine` declined** (v0.6 §13); reproposed, not assented | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
 | Secret-use evidence (lease, revocation, mount and rotation metadata) exposed as an engine surface | secret-abuse posture | `secrets-engine` | no engine surface exists; kings-guard consumes fixtures only | 2026-11-28 |
-| Containment surface — reduce authority, require step-up, isolate a workload — callable as a deterministic engine API, available while an incident is in progress | bounded response | `access-engine`, runtime engines | no engine surface exists; ruled pending in v0.4 §9.2, degraded-mode fallback ruled into the engine by §9.3 | 2026-11-28 |
+| Actuation surface — reduce authority, require step-up, isolate a workload — as a deterministic engine API carrying a decision record | containment kings-guard **proposes but does not own** | `access-engine` + runtime PEPs; not reviewed (`FLEX-DEC-2026-002`) | ruled an Engine concept held at zero (v0.6 §9.2); recorded here as a dependency, not a kings-guard gap to close | 2026-11-28 |
 
 Until a gap closes, the corresponding posture lane stays advisory and
 fixture-driven. kings-guard MUST NOT open a direct path to the Tooling system