Resolve user info from token claims; drop /api/external/userinfo dependency

[petrikero]

Draft / proposal — opening for discussion before polishing. See open questions at the bottom.

Motivation

The portal is sunsetting /api/external/userinfo. An endpoint can only be deleted once its last caller is gone, so a partial migration buys nothing toward that goal. This removes every CLI invocation of it, sourcing the user profile from the token claims the CLI already holds.

What it does

auth.FetchUserInfo (HTTP GET to UserInfoEndpoint) is replaced by auth.ResolveUserInfo(tokenSet), which reads claims locally — no network call:

• Access token (always present): sub, plus the Metaplay-namespaced https://schemas.metaplay.io/email.
• ID token (human logins): standard OIDC email, given_name, family_name, name — overrides where present.
• Machine logins (no ID token) resolve to sub (+ namespaced email if present).

Callers updated:

• get kubeconfig (dynamic): label = resolved email, falling back to sub. The label is cosmetic — target_environment.go:277 notes it's "stored in the kubeconfig but not used otherwise"; auth is the metaplay get kubernetes-execcredential exec plugin.
• machine-login: success line now shows clientId (already known) instead of a fetched name.
• auth whoami: resolves from claims.

UserInfoEndpoint config is retained (field, defaults, and metaplay-project.yaml validation) for config compatibility, marked Unused in code since the CLI no longer calls it.

Why the tokens carry this (SDK refs)

• AuthUi/src/routes/consent.ts:34-68 — sets email/given_name/family_name/name on the id_token for human logins (when email/profile scopes are granted; the CLI requests both).
• DeveloperPortal/.../ory/enrichclaims.post.ts:401-411 — adds https://schemas.metaplay.io/{email,roles} to both tokens; the CLI client is not in the portal ignore-list.

Impact

• Functional: none. kubectl auth is unchanged (exec plugin); the kubeconfig label is cosmetic.
• Cosmetic losses: whoami no longer shows picture (not in any token); machine whoami/machine-login show clientId/sub rather than a name. whoami --format json will have an empty picture.
• Humans keep name + email (from the id_token). Reliable name/email across refreshes depends on Retain id_token and refresh_token across token refreshes #160 (id_token retention), now merged.

Verified live

auth whoami -v on a real session: resolves from claims with no network call (instant), email populated from the namespaced access-token claim even without an id_token, sub present. Unit coverage added in login_test.go (human id-token, machine access-token, id-token override, no-subject error).

Open questions for review

1. get kubeconfig's AUTH_PROVIDER arg is now unused (its only role was selecting the userinfo endpoint). Kept registered for compatibility — remove it, or keep as a no-op?
2. Dropping picture from whoami acceptable? (Alternative: keep a single whoami-only call to the non-deprecated /api/v1/users/me.)
3. The namespaced-email path relies on enrichclaims, which the portal itself plans to deprecate. Standard id-token email is the durable human source; machines would lose email if that webhook goes away. Acceptable, or do machines need a successor endpoint?
4. UserInfoEndpoint is retained but unused — keep it indefinitely for config compatibility (current choice), or plan removal later?