feat: adopt security zones and explicit workload refs

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1

wiki/WorkloadSecurityPosture.md

@@ -111,6 +111,28 @@ This is the practical bridge from WARDEN-WP-0014 (`warden access`) to WP-0015: a
 assist can remove manual secret handling friction, while posture/maturity decides
 whether the secret may flow at all.
 
+## Security-zone consumer contract
+
+Security zones are now the prescriptive sibling of this descriptive posture
+model. `zone-engine` owns `security-zones_v0.1`; ops-warden follows it as a
+consumer under `ADR-0009`.
+
+- Workload maturity and data classification are admission evidence, not zone
+  names and not control stance.
+- The workload owner declares authoritative `workload_identity` and `zones:` in
+  the same `tenancy.yaml` service entry.
+- Credential lanes and actor resources reference that workload explicitly.
+  Managed deployables use Repo Manager's exact `(rapp_id, name, deployable?)`
+  tuple; independent operational workloads reference their owner declaration.
+- Missing identity, membership, or evidence resolves `unknown`. No compiler may
+  infer it from a path, repository owner, actor class, or environment.
+- flex-auth owns pre-sign stance; ops-warden owns PEP dependency failure behavior,
+  the agent read boundary, and `warden plan` escalation behavior.
+
+Ops-warden declares `z1-operational` with M1/internal/medium evidence. That is an
+accuracy statement, not a target: M2 remains unavailable until SLO history,
+on-call, and incident/recovery evidence exist.
+
 ---
 
 ## Canon layering (where each part lands)