Auth docs and example app trust the IdToken without verifying its signature #37

The docs tell pack authors to base64-decode the IdToken cookie without checking the signature, because "Envoy Gateway already verified the signature":

• docs/site/src/content/docs/auth-flow.md:141-142 (and the mirror in docs/auth-flow.md)
• README.md:473-474, which also lists groups as a claim to extract
• examples/auth-fastapi/README.md:98-99
• examples/auth-fastapi/app/main.py:26-29; examples/auth-fastapi/app/main.py:59-61 accepts the first cookie whose name starts with IdToken-

That reasoning doesn't hold.

• Envoy's oauth2 filter (Envoy 1.36, shipped by the Envoy Gateway v1.6.2 that NIC pins) does not verify the JWT signature. It parses the token only to read exp, and protects its own cookies with an HMAC.
• The app is reachable without going through that filter. The Service is ClusterIP, and neither the template, the operator nor NIC creates a NetworkPolicy, so any pod in the cluster can call it directly. publicRoutes get a separate HTTPRoute with no SecurityPolicy attached (internal/controller/reconcilers/routing/httproute.go:299-311), so requests on those paths never touch the OIDC filter.

On any of those paths a caller can send whatever IdToken-* cookie they want, and the app treats its claims as real. The example only displays the claims, but the template is meant to be copied, and the README points readers at groups.

Fix

• Verify the token in the example app and in the docs snippet: fetch the realm JWKS from the issuer-url key in the <name>-oidc-client secret, and check signature, iss, aud and exp.
• Read the exact cookie name rather than any IdToken- prefix.
• Add an optional NetworkPolicy to the examples that limits ingress to the Envoy proxy pods, and explain why.
• Reword the auth-flow page: the gateway handles login, and the app has to verify any identity it acts on.

Verified against this repo at 4e50cd0, nebari-operator v0.1.1 (same commit as operator main), and NIC v0.14.0.