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/config/validate.go

@@ -89,8 +89,28 @@ func ValidateConfig(cfg *Config) []string {
 					errs = append(errs, prefix+": tokenLifetime must be between 1m and 1h")
 				}
 			}
-		} else if c.TokenLifetime != "" {
-			errs = append(errs, prefix+": tokenLifetime is only supported for client_credentials clients")
+		} else {
+			if c.TokenLifetime != "" {
+				errs = append(errs, prefix+": tokenLifetime is only supported for client_credentials clients")
+			}
+			// Service-identity fields are read only on the client_credentials
+			// path. On a browser client they are silently ignored, and the
+			// tenant one is a trap worth failing on: an approver client
+			// registered with tenant: tenant:platform starts cleanly and then
+			// issues tokens carrying the directory tenant, which a resource
+			// server comparing tenant exactly will refuse. That surfaces as a
+			// mysterious failed approval, not as a registration defect
+			// (KEY-WP-0028). Human tenant comes from the directory user; see
+			// docs/approval-engine-auth-contract.md.
+			if c.Tenant != "" {
+				errs = append(errs, prefix+": tenant is only read for client_credentials clients; a browser client's tenant claim comes from the directory user, so this value would be silently ignored")
+			}
+			if c.ServiceSubject != "" {
+				errs = append(errs, prefix+": serviceSubject is only read for client_credentials clients; a browser client's subject is the directory user")
+			}
+			if len(c.Roles) > 0 {
+				errs = append(errs, prefix+": roles is only read for client_credentials clients; a browser client's roles come from the directory user")
+			}
 		}
 		// Warn about wildcard redirect URIs (they are blocked at runtime anyway).
 		for _, uri := range c.RedirectURIs {