What this PR does / why we need it:

Extracts groups and namespaces claims from the decoded JWT in OidcTokenParser.user_details_from_access_token() and passes them to the User object.

Previously, the OIDC token parser only read preferred_username and resource_access roles from the JWT, always returning User(username, roles) with empty groups and namespaces. This meant that GroupBasedPolicy, NamespaceBasedPolicy, and CombinedGroupNamespacePolicy could never grant access for OIDC-authenticated users — even when the JWT contained valid claims.

Server-Side Changes

Files: oidc_token_parser.py, utils.py
When auth.type: oidc, the Feast server now handles two types of incoming tokens:

• Keycloak JWTs (from human users via UI/Swagger) — validated against Keycloak JWKS, extracts preferred_username, groups, and roles. Used by GroupBasedPolicy.
• Kubernetes SA tokens (from workbench pods) — detected via kubernetes.io claim, delegated to existing KubernetesTokenParser which validates via TokenAccessReview and extracts namespace. Used by NamespaceBasedPolicy.
  Token type detection happens before any cryptographic validation — a lightweight unverified decode checks for the kubernetes.io claim. If the K8s API is unavailable (non-K8s deployment), the server falls back to Keycloak-only mode.

Client-Side Changes

Files: oidc_authentication_client_manager.py, auth_model.py, repo_config.py
OidcAuthClientManager.get_token() now supports multiple token sources with clear priority:

• Explicit config (exclusive — only one is used): token, token_env_var, or client_secret + IDP network call
• Bare config fallbacks (when nothing explicit is set): FEAST_OIDC_TOKEN env var, then mounted SA token file
  This means a workbench pod with just auth: {type: oidc} automatically picks up its SA token. Human users can set FEAST_OIDC_TOKEN. Existing client_credentials/ROPG flows are unchanged.

Which issue(s) this PR fixes:

#6088

Misc