Measure the join: 1 of 27 lanes, and correct my own over-correction

T02 said no join key exists — too strong. The correction said the workload side
exists "and most of the join with it" — too optimistic, and it was an inference
from structure rather than a measurement. Computed, the join matches exactly one
lane: issue-core-ingestion-api-key.

rapp-qonto-keycape-client demonstrates the predicted naming failure: the path
offers keycape-client and rapp-qonto while the rapp declares name qonto, so
neither candidate matches.

The gap is therefore not a missing key but missing declarations. Thirteen lanes
name something plausible that no rapp declares as a workload; thirteen more are
not KV addresses at all.

This blocks stance modelling rather than unblocking it, and the tempting escape —
binding zones to something other than a workload for lanes that have none —
would quietly undo the subject decision. Recorded as a decision for repo-manager
and net-kingdom rather than resolved here.

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

workplans/ZONE-WP-0001-security-zone-model.md

@@ -375,6 +375,54 @@ This reopens the ownership question favourably: zone-engine does **not** need to
 build a workload registry. It needs to consume `rapp` declarations and ops-warden's
 `dataclass_floor`, and to ask ops-warden for one explicit field.
 
+### Measured 2026-08-20 — the join covers one lane in twenty-seven
+
+The correction above was itself too optimistic. Saying "the workload side exists,
+and most of the join with it" was an inference from structure; computing it gives
+a different answer. `ops-warden/scripts/report_workload_join.py`:
+
+```
+declared workloads (rapp-*):  8
+lanes matched to a workload:  1
+lanes unmatched:             13
+lanes with no usable path:   13
+```
+
+The single match is `issue-core-ingestion-api-key` → workload `issue-core`,
+`confidential`, `criticality: high`, floor `M2`.
+
+`rapp-qonto-keycape-client` does **not** match, and demonstrates the predicted
+failure exactly: the path offers `keycache-client` and `rapp-qonto`, while the
+rapp declares `workload_identity.name: qonto`. Neither candidate is the declared
+name.
+
+**So the gap is not a missing key. It is missing declarations.** Thirteen lanes
+name something plausible — `whynot-design`, `llm-connect`, `forgejo-admin`,
+`audit-core`, `email-connect`, `company-email` — that no rapp declares as a
+workload. Those are real running things holding real credentials, and the
+workload registry does not know they exist. Thirteen more lanes have no usable
+path at all: SSH, policy checks, tunnels, broker grants and pattern lanes, which
+are not KV addresses and never will be.
+
+**Consequence for the model, and it is a hard one.** A zone whose subject is the
+workload cannot govern a credential estate in which 26 of 27 lanes have no
+identifiable workload. T03 cannot proceed to stance modelling on this basis.
+Either:
+
+- **the declaration surface must grow** to cover what actually holds credentials
+  — which is `rapp`/`repo-manager` work, not zone-engine's, and is a far larger
+  ask than "add one field"; or
+- **zones bind to something other than a workload for the lanes that have none**
+  — which reopens the subject question that the operator's direction settled, and
+  should not be done quietly to make the model fit.
+
+The second is the tempting one and is how a model quietly becomes wrong. Take the
+first to `repo-manager` and `net-kingdom` before modelling further.
+
+The three defects listed above stand, but they are second-order next to this: an
+explicit `workload:` field on catalog entries is still worth having, and it does
+not help until there are workloads to point it at.
+
 **Build stage is a positional fact, not a concession.** The organization is in
 `build`; the default stance is permissive and zones tighten by *admission*,
 rather than by raising a global floor. That is what makes this model compatible