feat: pass through auth.denyRedirect to the NebariApp spec

[tylerpotts]

The chart renders NebariApp.spec.auth but has no way to set denyRedirect, the nebari-operator field that returns 401 instead of an OIDC redirect for matching requests.

Without it, gateway-enforced OIDC (enforceAtGateway, nebi's default posture: no in-app SSO proxy) is vulnerable to the PKCE state-cookie race the operator API documents: on page load the browser fires the document request plus site.webmanifest/favicon/asset requests in parallel, each gets its own 302-to-Keycloak with a fresh state cookie, they overwrite each other, and the document's callback fails state validation and restarts the flow. On a deployment behind a private CA (Concepts-NREC) this presents as an infinite login redirect loop on nebi's UI: the browser console shows the webmanifest request captured mid-OAuth-flow (its URL encoded in the state parameter) while Keycloak logs no client errors, since codes are issued fine and rejected client-side by Envoy.

Changes:

• templates/nebariapp.yaml: render nebariapp.auth.denyRedirect verbatim into spec.auth.denyRedirect
• values.yaml: denyRedirect: [] default (rendered output unchanged when unset) with a recommended Sec-Fetch-Dest rule documented
• Chart.yaml: 0.1.2 -> 0.1.3 (release workflow cuts the release on merge)

Verified with helm template: the documented example renders into the NebariApp spec correctly, and default values render identically to 0.1.2.

[tylerpotts]

this isn't needed right now