CRD reference claims only the app's pods can read the OIDC client secret #39

docs/site/src/content/docs/nebariapp-crd-reference.md:69 says: "The operator scopes RBAC on the OIDC client Secret to this ServiceAccount, so only the app's pods can read its credentials." The wording comes from the operator's field comment (api/v1/nebariapp_types.go:53-55).

The operator creates one Role granting get on <name>-oidc-client, bound to serviceAccountName (internal/controller/reconcilers/auth/rbac.go:33-91). That adds access for one ServiceAccount. It doesn't take access away from anyone else:

• Kubernetes RBAC is additive. Anyone who already has get secrets in the namespace, such as namespace admins, keeps it.
• Pods don't read env or volume secrets through their ServiceAccount; the kubelet fetches them. Any pod in the namespace, under any ServiceAccount, can mount the secret, so anyone who can create pods there can read it.
• The operator holds cluster-wide secret access (config/rbac/role.yaml:23-33), and Envoy Gateway reads the secret to configure OIDC.

docs/site/src/content/docs/auth-flow.md:207-214 has the related mechanism wrong too: secretKeyRef works without the Role. The Role only matters when the app reads the secret through the Kubernetes API.

Fix

Say what the Role does: it lets the app's ServiceAccount read the secret through the API. Anyone with pod-create or secret-read rights in the namespace can also read it. Raise the field comment wording upstream in nebari-operator.

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