ci: adopt the shared pack-release.yaml reusable workflow (suggestion)

Suggestion

nebari-dev/.github now ships a reusable release workflow, pack-release.yaml@v1, and llm-serving-pack already consumes it. This proposes migrating this pack's Release Chart workflow (.github/workflows/release.yaml) onto it so pack releases share one maintained implementation across the org.

Filing as a suggestion for maintainers to weigh: there is real drift between the shared workflow's assumptions and this pack's current release process, so adopting it is not a no-op.

What the shared workflow does

Given chart-path, chart-name, and tag-paths, it:

1. reads the version from <chart-path>/Chart.yaml;
2. is idempotent (skips if the <chart-name>-<version> release already exists);
3. pins each tag-paths entry (a dotted values.yaml key) to sha-<release-commit-sha> in the working copy only (never committed back);
4. helm packages the chart, attaches the .tgz to a GitHub Release, auto-detecting --prerelease from a - in the version;
5. syncs the packaged chart source to nebari-dev/helm-repository via the shared sync-chart action (opens a PR there; OCI publish to quay happens downstream on merge).

Benefits: one maintained release path, automatic prerelease detection, and the central helm-repository sync we added in #140 - with far less bespoke YAML in this repo.

Drift from this pack's current release process

1. Committed-tag model vs pin-at-release. llm-serving-pack keeps tag: "latest" placeholders and lets the release workflow pin them. This pack instead commits real sha-<build-sha> tags via the bump-image-tags.yaml bot after each image build. The shared workflow always re-pins tag-paths to the release commit's SHA, which is a different SHA than the committed build SHA.
2. Profile image refs the pin script cannot touch. The shared pin_image_tags.py only rewrites simple leaf tags (e.g. jupyterhub.hub.image.tag). This pack's jupyterlab image also appears as ~6 full repo:tag strings inside the jupyterhub.custom.profiles list (kubespawner_override.image, profile_options.image.choices.*). The script has no list-index support and does not rewrite the tag portion of a full ref, so it cannot pin those. Today bump_image_tags.py keeps all of them in sync.
3. Image build trigger. build-images.yaml builds only on images/** changes, so a release commit (a Chart.yaml bump) produces no images for its SHA. The shared workflow's pinning assumes those images exist (llm-serving-pack builds on Chart.yaml changes for exactly this reason).
4. Per-repo gh-pages index. The current release.yaml also maintains this repo's own gh-pages Helm index. The shared workflow drops it - the central nebari-dev/helm-repository is now the source of truth (matches llm-serving-pack).

Suggested reconciliation

Options, roughly increasing in effort:

• A - Migrate now, keep the bump bot. Call pack-release.yaml@v1 with tag-paths: jupyterhub.hub.image.tag + jupyterhub.singleuser.image.tag; add Chart.yaml to build-images.yaml's trigger so release-SHA images exist; keep bump-image-tags.yaml as the source of truth for the profile refs; drop the bespoke gh-pages/release steps. Lowest risk. Known limitation: the shared workflow will not re-pin the profile refs, so they track the bump bot's build SHA rather than the release SHA (both images exist; the profile jupyterlab image may lag the default singleuser by one build).
• B - Full alignment. First extend pin_image_tags.py upstream in nebari-dev/.github to handle full-ref/list paths, then switch this pack to placeholder tags and retire bump-image-tags.yaml. Cleanest end state; spans two repos.
• C - Restructure the chart so the jupyterlab image is a single .tag leaf that the profiles template from, removing the full-ref duplication. Largest chart change; makes A/B trivial afterward.

A is the lowest-risk path if maintainers want to adopt this; B/C are good follow-ups for full parity with llm-serving-pack.

Start by comparing .github/workflows/release.yaml and build-images.yaml with nebari-dev/.github's pack-release.yaml@v1, then inspect the image-tag handling in bump_image_tags.py and pin_image_tags.py. Determine which reconciliation option maintainers want, including the profile image refs and gh-pages behavior. Done means the migration scope is agreed and the release, image, and chart-repository behavior are verified.