Provider-agnostic OIDC discovery for internal SecurityPolicy JWKS URI

Context

#61 fixed the broken JWKS path by hardcoding <issuerURL>/protocol/openid-connect/certs (Keycloak convention). The fix is correct for the only provider the pack currently supports, but it narrows the operator from "any OIDC provider" (which docs/design.md line 12 still claims) to "Keycloak only".

The architecture review on PR #62 flagged this and a follow-up docs note was added recording the Keycloak-specific assumption.

Fix

At reconcile time, fetch <issuerURL>/.well-known/openid-configuration once per model (or once per operator startup with a periodic refresh), parse jwks_uri from the response, and use that as the remoteJWKS.uri on the internal SecurityPolicy. Fall back to the current Keycloak-shaped path if discovery fails, so a transient Keycloak outage doesn't break reconciliation.

Considerations:

• Cache the discovery result so the operator isn't hammering Keycloak on every reconcile.
• Pass through cfg.OIDCIssuerURL validation: trim trailing slashes (already a latent issue in the current code, called out in PR #62 review).
• Decide whether discovery happens in the operator or at runtime by Envoy itself (some EG versions support discovery natively - worth investigating).

Test

Stand up a non-Keycloak OIDC provider (Dex against a static config, or Auth0 free tier) and confirm the operator builds a valid SecurityPolicy whose JWKS URL points at that provider's actual JWKS endpoint.

Read docs/design.md line 12 and inspect the reconcile path that sets the internal SecurityPolicy remoteJWKS.uri, along with cfg.OIDCIssuerURL validation. Investigate OIDC discovery, caching, fallback behavior, and whether Envoy supports it natively. Done means a non-Keycloak provider such as Dex or Auth0 produces a SecurityPolicy pointing to its actual JWKS endpoint without breaking the fallback path.