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

docs/tenant-claim-contract.md

@@ -170,6 +170,42 @@ two cannot drift apart silently.
 Covered by `src/internal/server/oidc/human_tenant_test.go`, including the
 relabel refusal.
 
+### The claim carries its provenance
+
+GH-DEC-2026-013 §5 found what the rules above leave unsaid: `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 admits an approver by exact-matching that string while its
+contract reads as though it relies on the first. The check is sound; the property
+a reader infers from it is absent. gate-house named the property and left the
+mechanism to us.
+
+Every token therefore carries `tenant_source` alongside `tenant`:
+
+| `tenant_source` | Meaning |
+| --- | --- |
+| `directory` | The identity layer asserted this zone about this person. Includes the agreement case — if a registration declared the same zone the directory did, the directory still asserted it, so the stronger provenance is the true one. |
+| `registration` | Supplied by the client registration for a person the directory has placed nowhere. A fact about the client, not about the person. Always the value on service tokens: there is no directory principal behind one. |
+| `default` | Nobody asserted a zone. This is the profile's non-empty default. |
+
+**The third value is not padding.** The ruling names two sources, but the code
+has three states, and labelling an unasserted default as `directory` would
+reproduce the same defect one level down — a consumer reading an assertion the
+identity layer never made. That is the unknown-versus-absent distinction
+GH-DEC-2026-011 §3 requires, applied to our own fallback rather than only to the
+case we were asked about.
+
+**For consumers.** Do not treat the three as equivalent for any decision that
+turns on a fact about the *person*. `registration` and `default` are not weaker
+evidence of the same thing; they are evidence of a different thing. What follows
+from that is the consumer's call — gate-house explicitly did **not** rule on
+whether approval-engine's exact-match admission is the right gate. Carrying
+provenance makes that question answerable; it does not answer it.
+
+`tenant_source` is advertised in `claims_supported`, and
+`TestIssuedTokensCarryTenantProvenance` asserts it reaches issued tokens on both
+grants, including the unasserted-default case.
+
 These are local issuance proofs. They are not live-rollout evidence; see
 `docs/approval-engine-auth-contract.md` and KEY-WP-0013-T02 for the deployment
 boundary. No token or secret values appear in this document or in test output.