Context

PR #111 split the SecurityPolicy OIDC endpoint overrides into browser-facing (Authorization, EndSession - public URL via KEYCLOAK_EXTERNAL_URL) and back-channel (Token - in-cluster URL). The Issuer field was deliberately not changed: GetIssuerURL still returns the in-cluster realm URL.

Concern

When Keycloak is configured with a public frontendUrl (recommended for production), it issues tokens with the iss claim set to the public URL. Envoy's SecurityPolicy.spec.oidc.provider.issuer is the in-cluster URL. Whether this is a problem depends on whether Envoy Gateway's OAuth2 filter validates the iss claim against the configured Issuer field. The OAuth2 filter mainly uses Issuer for OIDC discovery, but downstream consumers (e.g., LLM serving pack JWT validation) may compare the iss claim against an expected issuer string.

Investigate

1. Does Envoy Gateway's OAuth2 filter validate `iss` against `provider.issuer` beyond using it for discovery? If yes, a mismatch will fail token validation.
2. Do downstream services that read the `id_token` cookie compare `iss` against an expected value?
3. Should `provider.Issuer` be set from `KEYCLOAK_EXTERNAL_URL` (matching the iss claim Keycloak actually emits), with discovery falling through to the externally-fetched well-known doc?

Acceptance

A clear answer to whether the Issuer field needs to track ExternalURL too, with a test case demonstrating the chosen behavior.

Reference

Surfaced during code review of #111. Validation of the Nebari LLM Serving Pack fresh-install runbook (nebari-dev/nebari-llm-serving-pack#65) is the originating context.