Reference the shared nebari-dev/.github@v1 release workflows instead of shipping copies

The org now has shared reusable release workflows in nebari-dev/.github, tagged @v1 (pack-build-image.yaml and pack-release.yaml). nebari-dev/llm-serving-pack is the first consumer, and nebari-dev/data-science-pack migration is tracked in nebari-dev/data-science-pack#180.

This template still ships its own copies of build-image.yaml / release.yaml (and related CI), which every pack generated from it inherits as a copy. Those copies then drift from the shared versions pack-by-pack, which is exactly the problem the extraction was meant to end. The template should instead ship thin callers that uses: the @v1 reusable workflows, so a new pack gets a pointer that tracks fixes centrally rather than a frozen copy.

What this involves

• Replace the copied build-image.yaml / build-images.yaml / release.yaml (and the bump-image-tags workflow + scripts/bump_image_tags.py, if present) with thin caller workflows modeled on llm-serving-pack's .github/workflows/build-images.yaml + release.yaml, which call nebari-dev/.github/.github/workflows/pack-{build-image,release}.yaml@v1.
• Adopt the pin-at-release model: no bump-image-tags / BOT_PAT; image tags float on main and are pinned in the published chart at release time.
• Forward secrets.QUAY_USERNAME + secrets.QUAY_TOKEN from the caller (note QUAY_USERNAME is an org secret, not a variable).
• Include a .github/release.yml for categorized changelog notes, keyed on the template's standard labels.
• Placeholders for the per-pack bits a new pack fills in: the image list (name + build context) for build-images.yaml, and the chart-path / chart-name / tag-paths for release.yaml.

Blocking considerations (shared with #180)

• Multi-arch: pack-build-image@v1 is single-platform (amd64) via a platforms input; it has no native-per-arch digest-merge yet. If template-generated packs commonly need arm64, pack-build-image needs a multi-arch mode before the template defaults to it. Scope alongside data-science-pack#180.
• Bespoke pin targets: packs that pin more than simple <component>.image.tag dotted paths (e.g. jupyterhub profile lists) need an extension to the shared pin step or a pack-provided hook.

Doing this in the template propagates the shared pipeline to all future packs by default.

Start by comparing the template’s .github/workflows/build-image.yaml, build-images.yaml, release.yaml, and any bump-image-tags workflow with llm-serving-pack’s caller workflows. Read the shared pack-build-image.yaml and pack-release.yaml inputs, then verify the caller placeholders, forwarded secrets, and .github/release.yml requirements. Done means the template references the shared @v1 workflows without copied pipeline logic, while the multi-arch and bespoke pin-target constraints are resolved or explicitly handled.