Security Layer Model v0.3 — assign approvals and maturity

v0.2 recorded the approval object as the one open architectural hole, and
carried a latent instance of its own §9.1 rule: gate-house was catalogued as
owning conformance review with no engine to act through. Two engines were
seeded to close both.

- §9.4: the approval object goes to approval-engine — not Staff (§3.4 forbids
  the runtime state), not access-engine (an evaluator owning what it evaluates
  is self-dealing), not audit-core (append-only is the opposite property).
  access-engine consumes approvals as input claims under §6.2; audit-core takes
  the tamper-evident evidence. Operative state and evidence record are separate
  artifacts with separate owners.
- §9.5: graded progression goes to maturity-engine. gate-house judges and
  proposes; maturity-engine computes and remembers. Carries the guardrail that
  a level may never gate a decision directly — under §6.1 that would be a
  second decision point by the graded back door.
- §4 catalog gained both engines; §13 register updated.

Status proposed: the new engines are seeded by owner direction with no other
side to assent yet, and the approval evidence half needs audit-core's assent.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9

README.md

@@ -12,7 +12,7 @@ The dynamic, self-optimizing security platform is the long-term direction in
 ## Orientation
 
 - [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
-- [Security layer model](canon/standards/security-layer-model_v0.2.md) — how the
+- [Security layer model](canon/standards/security-layer-model_v0.3.md) — how the
   security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
   layer may own
 - [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)