Carry the tenant claim's provenance, and correct a guard the ruling voided

GH-DEC-2026-013 §5 is a finding nobody asked for and ours to implement: tenant is
a bare string, so a consumer cannot tell a zone the directory asserted about the
person from one a registration supplied about the client they came through.
approval-engine exact-matches that string while its contract reads as though it
relies on the first -- the check is sound and the property a reader infers from
it is absent. gate-house named the property and left the mechanism to us.

Every token now carries tenant_source beside tenant: directory, registration or
default. Advertised in claims_supported, and asserted at the token level on both
grants rather than only in the resolution function, since the claim a consumer
reads is the thing under obligation.

Three values where the ruling names two, which is the judgement here. Labelling
an unasserted profile default as directory would reproduce the same defect one
level down -- a consumer reading an assertion the identity layer never made. The
ruling cites GH-DEC-2026-011 §3 on unknown versus absent for the case it
examined; the same rule applies to our own fallback. The agreement case resolves
to directory deliberately: if a registration declares the zone the directory also
assigned, the directory did assert it, and reporting the weaker source would
understate what is known.

Also corrects the guard shipped in 5f516a0. Its failure message offered two ways
out of adding dynamic registration, and condition (b) voids the second: admitting
dynamic registration voids the registration-bound shape that day, whatever state
the adapter is in. The message named an inadmissible resolution in the exact
place someone would read it while making that change.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6

workplans/KEY-WP-0030-tenant-precondition-guard.md

@@ -9,6 +9,7 @@ owner: claude
 topic_slug: tenant-precondition-guard
 created: "2026-09-09"
 updated: "2026-09-09"
+state_hub_workstream_id: "9ed8f851-080a-5d15-8642-f799c2e3295c"
 ---
 
 `informed-decision` replied on KEY-WP-0013-T05 and asked for one thing that is
@@ -27,6 +28,7 @@ test about discovery metadata, not a warning about relabelling users.
 id: KEY-WP-0030-T01
 status: done
 priority: medium
+state_hub_task_id: "4729d591-39d4-5f33-bef8-db8057090913"
 ```
 
 `TestRegistrationBoundTenantRequiresStaticRegistration` asserts both halves
@@ -49,12 +51,65 @@ This is deliberately not a vote on the tenant question. It makes the preconditio
 of one option checkable; it does not choose between them, and if option 1 lands
 the capability and this guard are removed together.
 
+## Carry the tenant claim's provenance
+
+```task
+id: KEY-WP-0030-T03
+status: done
+priority: high
+```
+
+gate-house ruled on GH-DEC-2026-013 while this was in flight. Section 5 is a
+finding nobody asked for and is ours to implement: `tenant` is a bare string, so
+a consumer cannot tell a zone the directory asserted about the person from one a
+registration supplied about the client they came through. approval-engine
+exact-matches that string while its contract reads as though it relies on the
+first — the check is sound and the property a reader infers from it is absent.
+
+Every token now carries `tenant_source` beside `tenant`: `directory`,
+`registration`, or `default`. It is advertised in `claims_supported` and asserted
+on both grants at the token level, not only in the resolution function, because
+the claim a consumer reads is the thing under obligation.
+
+Three values where the ruling names two, and that is the substantive judgement
+here. Labelling an unasserted profile default as `directory` would reproduce the
+same defect one level down — a consumer reading an assertion the identity layer
+never made. The ruling cites GH-DEC-2026-011 §3 on unknown versus absent for the
+case it examined; the same rule applies to our own fallback, so the fallback is
+named rather than folded into the strongest neighbouring value.
+
+The agreement case resolves to `directory` deliberately: if a registration
+declares the zone the directory also assigned, the directory did assert it, and
+reporting the weaker source would understate what is known.
+
+## Condition (b) corrected a message I had just shipped
+
+```task
+id: KEY-WP-0030-T04
+status: done
+priority: high
+```
+
+The guard committed in `5f516a0` told a future reader that adding dynamic
+registration could be resolved by dropping the capability **or gating it to
+statically configured registrations**. Condition (b) voids the second: admitting
+dynamic registration voids the registration-bound shape that day, and the
+directory becomes the only source whatever state the adapter is in. gate-house
+strengthened our own "must be revisited" on the grounds that *revisited* implies
+the answer might survive review, and it would not.
+
+So the message offered a way out the ruling forbids, in the exact place someone
+would read it while making that change. Corrected the same day. Worth recording
+rather than quietly editing: the guard was written to force a confrontation, and
+a guard that suggests an inadmissible resolution is worse than none.
+
 ## What stays with the owners
 
 ```task
 id: KEY-WP-0030-T02
 status: done
 priority: medium
+state_hub_task_id: "32b10327-f55d-5a0e-a4bc-be92929469dc"
 ```
 
 `informed-decision` prefers option 2 and explicitly declines to treat that as the