Add identityFromToken to MCPExternalAuthConfig CRD

[jhrozek]

Add identityFromToken to MCPExternalAuthConfig CRD

Description

Phase 2 of the Snowflake / identityFromToken story (#5150). Add a
new optional identityFromToken block on the OAuth2UpstreamConfig
CRD type, with admission validation and regenerated CRD manifests.
This makes the field observable to operators and reachable through
kubectl apply. The runtime still ignores the field at this point —
the wiring lands in the next phase.

Context

The runtime helper from #5152 needs an operator-facing surface. A new
IdentityFromTokenConfig type with subjectPath, namePath, and
emailPath (gjson dot-notation paths) lives next to the existing
tokenResponseMapping and userInfoConfig types. The doc comment is
the authoritative place for the trust-model warning (claims are
trusted via TLS only, not cryptographically verified — prefer OIDC +
ID-token validation when verifiable identity matters) and the
subject-uniqueness guidance (scope is per-upstream-provider entry; use
distinct entries for distinct trust domains).

Cross-references in the existing tokenResponseMapping and
userInfoConfig doc comments help operators discover which block
applies to their provider.

Admission validation requires a non-empty subjectPath when the
block is set; namePath and emailPath are optional.

Dependencies: #5152 (runtime helper exists). The field is
structurally additive — existing manifests are unaffected.
Blocks: provider integration (next phase) cannot honour the field
until it exists in the CRD and runtime config.

Acceptance Criteria

• OAuth2UpstreamConfig gains an optional identityFromToken
  field of a new IdentityFromTokenConfig type carrying the three
  paths.
• The new type's doc comment includes:
  • The trust-model warning (TLS-only, prefer OIDC for verifiable
    claims).
  • The subject-uniqueness note (per upstream provider entry; use
    distinct entries for distinct trust domains).
  • Brief gjson dot-notation guidance with examples.
• Doc-comment cross-references between tokenResponseMapping,
  userInfoConfig, and the new identityFromToken are coherent.
• Admission validation rejects an identityFromToken block with
  an empty subjectPath.
• CRD manifests and reference docs are regenerated; task operator-generate, task operator-manifests, and task crdref-gen are idempotent.
• No runtime behaviour change: configs that set the new field are
  admitted but the embedded auth server still falls back to the
  existing identity-resolution paths until wiring lands in a later
  phase.
• task lint-fix, task operator-test, and task test pass.

Out of Scope

• Wiring the field into the OAuth2 upstream provider's
  identity-resolution chain — separate task.
• Operator-side translation from CRD field to runtime config —
  separate task.
• YAML examples — separate task.
• Synthesis-mode-detection awareness of the new field — separate task.