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

src/internal/server/oidc/token.go

@@ -197,7 +197,7 @@ func (h *TokenHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 	// Core claims required by net-kingdom/canon/standards/iam-profile_v0.3.md
 	// for every production token -- not scope-gated, unlike the recommended
 	// human claims above (KEY-WP-0005-T01).
-	tenant, err := humanTenant(h.ClientConfig[clientID], user)
+	tenant, tenantSource, err := humanTenant(h.ClientConfig[clientID], user)
 	if err != nil {
 		profileerrors.RejectedForSafety(
 			"tenant binding conflict",
@@ -206,6 +206,7 @@ func (h *TokenHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
 		return
 	}
 	claims["tenant"] = tenant
+	claims["tenant_source"] = tenantSource
 	claims["principal_type"] = "human"
 	claims["groups"] = nonNilStrings(user.Groups)
 	claims["roles"] = nonNilStrings(user.Roles)
@@ -335,12 +336,15 @@ func (h *TokenHandler) serveClientCredentials(w http.ResponseWriter, r *http.Req
 		tokenLifetime = client.TokenLifetime
 	}
 	claims := map[string]interface{}{
-		"iss":            h.Issuer,
-		"sub":            client.ServiceSubject,
-		"aud":            accessAudience(client),
-		"exp":            now.Add(tokenLifetime).Unix(),
-		"iat":            now.Unix(),
-		"tenant":         client.Tenant,
+		"iss":    h.Issuer,
+		"sub":    client.ServiceSubject,
+		"aud":    accessAudience(client),
+		"exp":    now.Add(tokenLifetime).Unix(),
+		"iat":    now.Unix(),
+		"tenant": client.Tenant,
+		// A service client's tenant is always registration-supplied: there is no
+		// directory principal behind it to assert one (GH-DEC-2026-013 §5).
+		"tenant_source":  TenantSourceRegistration,
 		"principal_type": "service",
 		"groups":         []string{},
 		"roles":          nonNilStrings(client.Roles),
@@ -433,16 +437,57 @@ func effectiveTenant(user *domain.User) string {
 // This is only safe because client registrations are static and
 // deployment-owned; KeyCape excludes dynamic client registration by design. A
 // self-service client that could name its users' tenant would be an escalation.
-func humanTenant(client *domain.Client, user *domain.User) (string, error) {
+func humanTenant(client *domain.Client, user *domain.User) (string, string, error) {
 	if client == nil || client.Tenant == "" {
-		return effectiveTenant(user), nil
+		if user.Tenant != "" {
+			return user.Tenant, TenantSourceDirectory, nil
+		}
+		return defaultTenant, TenantSourceDefault, nil
 	}
-	if user.Tenant != "" && user.Tenant != client.Tenant {
-		return "", fmt.Errorf("client %q binds tenant %q but the directory assigns this user a different tenant", client.ClientID, client.Tenant)
+	if user.Tenant != "" {
+		if user.Tenant != client.Tenant {
+			return "", "", fmt.Errorf("client %q binds tenant %q but the directory assigns this user a different tenant", client.ClientID, client.Tenant)
+		}
+		// Agreement: the directory did assert this about the person, so the
+		// stronger provenance is the true one.
+		return user.Tenant, TenantSourceDirectory, nil
 	}
-	return client.Tenant, nil
+	return client.Tenant, TenantSourceRegistration, nil
 }
 
+// Tenant provenance values for the tenant_source claim (GH-DEC-2026-013 §5).
+//
+// A bare tenant string cannot tell a consumer whether the identity layer
+// asserted the zone about this PERSON or a registration supplied it 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, so the
+// check is sound and the property a reader infers from it is absent. The ruling
+// requires the claim to carry its provenance and forbids a consumer treating the
+// two as equivalent for any decision turning on a fact about the person. It names
+// the property; the field is ours.
+//
+// Three values, not the two the ruling names, and the third is the point. A
+// tenant nobody asserted -- neither directory nor registration, just the
+// profile's non-empty default -- is not directory-asserted, and labelling it so
+// would reintroduce the same defect one level down: a consumer would read
+// "directory" for a fact the directory never stated. That is the unknown-versus-
+// absent distinction the ruling cites from GH-DEC-2026-011 §3, applied to our own
+// fallback rather than only to the case we were asked about.
+const (
+	// TenantSourceDirectory: the identity layer asserted this zone about this
+	// person. Includes the agreement case, where a registration declared the
+	// same zone the directory did -- the directory still asserted it.
+	TenantSourceDirectory = "directory"
+
+	// TenantSourceRegistration: supplied by the client registration for a person
+	// the directory has placed nowhere. A fact about the client, not the person.
+	TenantSourceRegistration = "registration"
+
+	// TenantSourceDefault: nobody asserted a zone; this is the profile default,
+	// emitted because the profile requires a non-empty tenant. Weaker than both.
+	TenantSourceDefault = "default"
+)
+
 // nonNilStrings returns s, or an empty (non-nil) slice if s is nil, so the
 // claim always serializes as `[]`, never `null` -- the profile requires
 // groups/roles to be present, "possibly empty", not absent.