Let a human token carry the zone it is issued into, without relabelling anyone

KEY-WP-0013-T05's tenant blocker did not need the decision it was waiting on. The
two proposed resolutions differ in where a human's tenant comes from -- the
directory record, or the client registration -- and an implementation exists that
is correct under either, so the choice can be made later without another
migration.

A client registration may now declare a tenant. humanTenant() resolves it by four
rules: no declaration keeps the directory answer unchanged; a declared zone
applies where the directory has placed the user nowhere; agreement passes; and a
declared zone conflicting with a directory assignment refuses issuance rather
than relabelling the user.

The refusal is the design, not an edge case. A registration can bind a zone for
unplaced users and can never move a placed one, so this gets the approval chain
its tenant:platform without writing a general cross-tenant override into the
issuer. It fails closed rather than picking a winner, because either answer would
be a silent cross-tenant assertion, and it reports 403 with
error_type: tenant_binding so an operator can tell a misconfigured registration
from a rejected login. If the owners later populate directory tenants, the same
code stops supplying the zone and starts enforcing agreement with it.

Safe only because client registrations are static and deployment-owned. The
tenant contract records that this rule must be revisited if dynamic client
registration is ever admitted.

Tests cover all four rules; neutering the conflict check fails the relabel test
rather than passing silently.

T05 now waits on one thing only: the client_id and callback URI from
informed-decision once it has a deployed origin.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1182213@bnt-lap001
Assistant-Session: 966597b9-ae61-46a4-8b9e-1594ab3ec4ad

src/internal/server/oidc/token.go

@@ -8,6 +8,7 @@ import (
 	"crypto/subtle"
 	"encoding/base64"
 	"encoding/json"
+	"fmt"
 	"net/http"
 	"net/url"
 	"strings"
@@ -196,7 +197,14 @@ 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 := effectiveTenant(user)
+	tenant, err := humanTenant(h.ClientConfig[clientID], user)
+	if err != nil {
+		profileerrors.RejectedForSafety(
+			"tenant binding conflict",
+			"tenant_binding",
+		).Write(w, http.StatusForbidden)
+		return
+	}
 	claims["tenant"] = tenant
 	claims["principal_type"] = "human"
 	claims["groups"] = nonNilStrings(user.Groups)
@@ -398,6 +406,43 @@ func effectiveTenant(user *domain.User) string {
 	return defaultTenant
 }
 
+// humanTenant resolves the tenant claim for a human token (KEY-WP-0013-T05).
+//
+// A human's tenant is normally a property of the person, read from the
+// directory. But the approval chain is bound to the landlord zone by decision
+// 5ed3fb35-eca9-413a-82b9-95171ba85bf6, and approval-engine compares the claim
+// by exact string equality, so an approver client has to be able to state the
+// zone it issues into. Without this every human token fell back to
+// defaultTenant and would have been refused downstream -- as a failed approval
+// rather than as a registration defect.
+//
+// The rule is deliberately not an override:
+//
+//   - no client tenant declared  -> the directory answer, unchanged;
+//   - declared, user unassigned  -> the declared zone;
+//   - declared and equal         -> agreement, no ambiguity;
+//   - declared and different     -> refuse to issue.
+//
+// So a registration can bind a zone for users the directory has not placed, and
+// can never relabel a user the directory HAS placed into a different one. That
+// last case fails closed rather than picking a winner, because either answer
+// would be a silent cross-tenant assertion. It also means this stays correct if
+// the directory later populates Tenant: the same code turns from supplying the
+// zone into enforcing agreement with it, with no second migration.
+//
+// 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) {
+	if client == nil || client.Tenant == "" {
+		return effectiveTenant(user), 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)
+	}
+	return client.Tenant, nil
+}
+
 // 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.