ci: migrate release and image-build workflows to shared reusable workflows

[dcmcand]

What & why

Migrates the template's release and image-build workflows off their hand-rolled implementations onto the shared reusable workflows in nebari-dev/.github, matching what llm-serving-pack uses. The template is the canonical copy-paste reference for pack authors, so it should demonstrate the standardized release-engineering pattern.

Closes #27.

Changes

• release.yaml → thin caller of nebari-dev/.github/.github/workflows/pack-release.yaml@v1 for the auth-fastapi example (the only example with a first-party image, so the one that meaningfully exercises tag-paths pinning). Triggers on push to main when examples/auth-fastapi/chart/Chart.yaml changes. Drops the self-hosted gh-pages Helm index in favor of syncing to the central nebari-dev/helm-repository.
• build-image.yaml → build-images.yaml → single job calling pack-build-image.yaml@v1 (copies the llm-serving-pack structure). Publishes to GHCR + Quay with sha-<short> + latest; also triggers on the chart's Chart.yaml so the release commit produces the sha-pinned image the release workflow references.
• Repo rename fallout: the reusable image workflow derives its path from the repo name, which was renamed to software-pack-template. Updated examples/auth-fastapi/chart/values.yaml image.repository and the local build/load tags in test.yaml / test-integration.yaml to the new GHCR path, plus README badges/file-tree/docker run examples, the auth-fastapi README, and the two docs "use this template" links. CF_PROJECT in the docs workflows is intentionally left unchanged (the Cloudflare project name is independent of the GitHub repo name).
• Docs: README Build Images / Release sections rewritten for the reusable flow, including the official-packs-only constraint; release-readiness checklist wording updated from the old "Helm repo index" model to the helm-repository sync model.
• Chart bump: examples/auth-fastapi/chart/Chart.yaml version 0.1.0 → 0.1.1, to exercise the release pipeline on merge (see Notes).

Manual prerequisite (official packs)

The shared image workflow does not create Quay repositories. Before the first image push, a maintainer must create quay.io/nebari/software-pack-template-auth-fastapi-example under the nebari org and grant the CI robot write access (public if the pack is public). GHCR auto-creates on push. This is documented in the README "Build Images" section. The NEBARI_HELM_REPO_TOKEN, QUAY_TOKEN, and QUAY_USERNAME secrets are provided organizationally to public nebari-dev repos.

Verification

• actionlint clean on all changed workflows.
• helm lint passes (NebariApp disabled and enabled); helm template renders the new image path; helm package succeeds.

Notes

• This PR intentionally bumps Chart.yaml to 0.1.1 to exercise the release pipeline end-to-end. Squash-merging to main will therefore (1) run build-images.yaml, publishing the auth-fastapi image to the new GHCR + Quay paths at sha-<merge-commit>, and (2) run release.yaml, creating a GitHub Release my-pack-0.1.1 and opening a sync-chart PR against nebari-dev/helm-repository seeding charts/my-pack.
• chart-name is the placeholder my-pack, so the nebari-dev/helm-repository sync PR is a smoke-test artifact: it should be closed, not merged (my-pack is not a distributable chart). It is human-gated, so nothing publishes to quay.io/nebari/charts unless that PR is merged.
• Only auth-fastapi is wired to releases; basic-nginx (upstream image) and wrap-existing-chart (podinfo subchart) have no first-party image to pin.

[github-actions]

📄 Docs preview for worktree-migrate-reusable-release-workflows:
https://worktree-migrate-reusable-re.nebari-software-pack-template.pages.dev