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>

docs/estate-partition-2026-08-19.md

@@ -216,7 +216,7 @@ The missing join found in §4 is therefore not a tidy-up. **It is the model.**
 > **Corrected 2026-08-20.** "No registry carries a join key" was too strong — it
 > was concluded from ops-warden's catalog alone, the one place a *workload*
 > declaration would not live. `rapp-*/declarations/rapp.yaml` declares
-> `workload_identity` with `data_classification` and `criticality` for nine
+> `workload_identity` with `data_classification` and `criticality` for eight
 > workloads, and ops-warden's `dataclass_floor` already maps classification to
 > `M0`–`M3`. The chain exists and spans two repos. What is genuinely missing is
 > an explicit `workload:` field on catalog entries — the key is currently only

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

@@ -337,7 +337,7 @@ it.** T02 concluded no registry carries a join key. That was too strong; it was
 derived from ops-warden's catalog alone, which is the one place a workload
 declaration would *not* live.
 
-`rapp-*/declarations/rapp.yaml` is the workload declaration surface. **Nine**
+`rapp-*/declarations/rapp.yaml` is the workload declaration surface. **Eight**
 rapps declare `workload_identity` (`name`, `principal`, `service_account`,
 `tenant`) together with `data_classification`, `criticality`
 (`low`/`medium`/`high`/`critical`), `readiness_state`, and `bound_reefs`.
@@ -366,7 +366,7 @@ blocking unknown:
 2. **Vocabulary mismatch.** rapps declare `public`, which `dataclass_floor` does
    not map. `rapp-policy-nexus` is `public` today, so the floor cannot grade it.
    One of the two vocabularies must move; canon owns `DataClassification`.
-3. **Coverage is partial.** Nine workloads are declared; ops-warden's catalog
+3. **Coverage is partial.** Eight workloads are declared; ops-warden's catalog
    yields ~17 distinct path identities. The unmatched remainder is the
    interesting set — it is where a lane exists for something that is not a
    declared workload at all.
@@ -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