ci(runway): name the iam-auth chart after the service

Why

The chart name becomes the Kubernetes Service name. The GKE network endpoint group is bound to that Service name. If the chart is renamed after the first deploy, the endpoint group stays bound to the old name, the pods report healthy, and the load balancer has no backend. This happened to iam-data-access staging on 2026-08-13 and took over three hours to fix (!499 (closed)).

The iam-auth-http chart has never been deployed, so renaming it now has no runtime effect. We use the name iam-auth because one chart should serve both Runway deployments once Fairway supports several listeners (gitlab-com/gl-infra/platform/runway/fairway#31 (closed)).

iam-auth gets two Runway deployments, iam-auth-ext-gke for HTTP and iam-auth-gke-grpc for gRPC (https://gitlab.com/gitlab-org/gitlab/-/work_items/587663). Both are added to this repository, each with its own runwayctl/kubernetes-v2-service include, and deploy the charts this repository publishes. !515 (merged) adds iam-auth-ext-gke, the first deployment of this chart, so this rename must merge before !515 (merged).

What this changes

• Moves .runway/iam-auth-http/fairway.yaml to .runway/iam-auth/fairway.yaml and sets metadata.name: iam-auth.
• Points the fairway/helm-chart include in .gitlab-ci.yml at the new path.
• scripts/sync-artifacts.sh copies chart/iam-auth instead of chart/iam-auth-http.
• docs/release.md and .ai/build-test-deploy.md name the new chart and path.

The commit uses a ci: prefix, so merging does not cut a release. The renamed chart is first published at the next fix: or feat: release.

Not in scope: the image name, the iam-data-access chart, the provisioner entries, and old chart/iam-auth-http versions in the registries. After this merges, !515 (merged) must be rebased to move deployment.yaml, values-staging.yaml and values-production.yaml to .runway/iam-auth/.

Impact check

Checked on 2026-09-02 against the live repositories:

• The iam-auth-http chart has never been deployed. The Runway deployment project iam-auth-ext-gke has never received an artifact. Vault paths, DNS and the provisioner entry use the Runway service id, not the chart name.
• A code search across the gitlab-org and gitlab-com groups finds iam-auth-http outside this repository in two places: the x-gitlab-svc header value in Workhorse's routes.go, and the Envoy route in sandbox-config that matches that header. The route sends traffic to the sandbox's own iam-auth Service, which the sandbox applies from its own manifests. Neither uses this chart.
• No reference in artifact-registry, gitlab-caproni, caproni-demo, the Runway provisioner, k8s-workloads or design-doc.
• Nothing in this repository's CI refers to the Fairway job names, which contain the manifest path. Renovate matches the Fairway pins by dependency name, and the component URL is unchanged.
• Old chart/iam-auth-http versions stay in the registries. chart/iam-auth is created on the first push.
• The only open merge request that touches .runway/iam-auth-http/ is !515 (merged).

Verification

• Rendered the chart from the old and the new manifest with Fairway 3.1.0 and diffed the output. Only names differ: the chart name, the template helper names, the appconfig-iam-auth ConfigMap and its CONFIG_DIR mount path, and the object names taken from metadata.name. No code in this repository uses that path directly.
• shellcheck scripts/sync-artifacts.sh is clean. The CI lint API accepts the pipeline file.
• The merge request pipeline runs the (dry-run) Fairway jobs for the new manifest path, which shows that the include path resolves and the chart generates.
• At the next fix: or feat: release, the mirror's tag pipeline publishes chart/iam-auth:<version> and sync-per-service-artifacts copies it to registry.gitlab.com/gitlab-org/auth/iam/chart/iam-auth.