rbac.bootstrap.hubClientId derivation uses literal "jupyterhub-" prefix; should use .Release.Namespace

Problem

After PR #74 flipped rbac.bootstrap.enabled: true as the chart default, the post-install/upgrade RBAC bootstrap Job started failing on real deployments with:

==> 2. hub OIDC client + service account
Traceback (most recent call last):
  File "/scripts/keycloak_rbac_bootstrap.py", line 521, in <module>
    sys.exit(main())
  File "/scripts/keycloak_rbac_bootstrap.py", line 265, in get_client_uuid
    raise RuntimeError(
RuntimeError: client 'jupyterhub-data-science-pack-nebari-data-science-pack' not found in realm 'nebari'

Root cause

The chart's values.yaml documents the auto-derive behavior:

ClientId of the hub OAuth client in Keycloak (created by the nebari-operator NebariApp). Leave empty to derive from the release + chart name (the operator's standard pattern: jupyterhub-<release>-<chart>). Override for non-standard client ids.

That assumption doesn't match the operator. nebari-operator actually builds the client id as <namespace>-<release>-<chart> — it uses the NebariApp's namespace as the prefix, not the literal string jupyterhub. So for a release data-science-pack of chart nebari-data-science-pack in namespace nebari-system, the operator provisions:

nebari-system-data-science-pack-nebari-data-science-pack

…but the chart's auto-derive produces:

jupyterhub-data-science-pack-nebari-data-science-pack

The two only agree when the NebariApp lives in a namespace literally named jupyterhub, which I'd guess only matches local-dev k3d clusters (which is plausibly where the assumption was first formed).

Fix

Replace the literal in the derivation with .Release.Namespace. Concretely in templates/keycloak-rbac-bootstrap-job.yaml (and any helper that owns the derivation):

- name: HUB_CLIENT_ID
  value: {{ default (printf "%s-%s-%s" .Release.Namespace .Release.Name .Chart.Name) .Values.rbac.bootstrap.hubClientId | quote }}

…and update the values.yaml comment to say "derive from .Release.Namespace-.Release.Name-.Chart.Name (the operator's standard pattern)".

Cluster impact (real deployment hitting this)

NIC's Hetzner cluster sync moved past e987b6d (alpha.12) to the merged PR #74 (0cdf3f2). The RBAC Job failed every post-sync run with the error above until we explicitly set rbac.bootstrap.hubClientId to the operator-provisioned name in deployment-level values (see openteams-ai/nic-deploy#12 for the workaround).

Every deployment using nebari-operator + a namespace that isn't named jupyterhub will hit this on first chart sync after the default flipped.

Related upstream change request

Even with this fix, the chart's RBAC Job is a workaround for a CRD gap on the operator side — NebariApp.auth.keycloakConfig supports groups and protocol mappers but not client roles. Tracked at nebari-dev/nebari-operator#119. Once that lands, the whole Job can go.

Start with templates/keycloak-rbac-bootstrap-job.yaml and the related values.yaml comment, then inspect how HUB_CLIENT_ID is derived. Update the derivation and documentation to use the release namespace, and render the chart to confirm the default matches the operator-provisioned client ID while preserving explicit overrides.