GKE: point the pipeline at this cluster's registry, over TLS

The GCP counterpart of devops-lib. Registered in Jenkins under the same
name, so consuming repos need no change: the two-line Jenkinsfile is
identical on both clusters, and which library it resolves to is a property
of the Jenkins running it.

Substantive changes, all consequences of GKE being a real cloud:

- Harbor speaks TLS here, so dind no longer passes --insecure-registry.
  It mounts the private CA at
  /etc/docker/certs.d/harbor.35.238.248.203.nip.io/ca.crt instead, from the
  registry-ca ConfigMap. This is not redundant with the node pool's trust:
  that covers pulls, performed by containerd on the node, while the push
  comes from dockerd in the build pod with its own trust store. Without it,
  pushes fail TLS verification while pulls of the same image succeed —
  which reads like a broken registry rather than a missing trust anchor.

- The registry hostname changes in the push target and all five fallback
  Dockerfiles. It still must be spelled identically everywhere, because
  Docker matches credentials and trust by exact hostname.

- helm_repo_url moves to cluster DNS. That clone runs in a build pod, so
  sending it out through the ingress and back would make the pipeline
  depend on Contour for pod-to-pod traffic. syncArgoApp already addressed
  ArgoCD this way and needed no change.

- build-tools.Dockerfile is removed: devops-base-images-gcp owns it now,
  next to the mirrored base images, and the pod references the result by
  tag at base-images/build-tools:1. The base-images project is public, so
  the pod can pull it before it has any credentials.

Verified: no homelab addresses remain; the pod template parses with the CA
mount, the new image and no insecure-registry flag; and every fallback
template's base image, with the default version buildDocker would pick, is
present in the mirror manifest — an unmirrored tag now fails the build
rather than silently falling back to Docker Hub.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LEsTefWWifp4ikvhHF5s6N

src/com/homelab/stages/buildDocker.groovy

@@ -20,15 +20,19 @@ import com.homelab.utilities.constructTemplate
 def run(Map config) {
     def tag = "${env.BUILD_NUMBER}-${env.GIT_COMMIT?.take(7) ?: 'dev'}"
     env.TAG = tag
-    // Was harbor-core.harbor.svc.cluster.local (cluster-internal Service
-    // DNS) — worked for this push, since it runs inside a pod with
-    // pod-network DNS (CoreDNS). But the actual Deployment's image PULL
-    // happens via containerd running on the node itself, using the
-    // node's host-level DNS resolver, which has no route to
-    // *.svc.cluster.local at all. Using the Contour ingress hostname
-    // instead makes the same reference resolvable from both contexts
-    // (nip.io resolves via normal public DNS, reachable from the host).
-    def image = "harbor.192.168.1.7.nip.io/${config.harbor_project}/${config.repo_name}:${tag}"
+    // The registry ingress hostname, not harbor-core.harbor.svc.cluster.local.
+    // Cluster DNS would work for this push, which runs inside a pod, but the
+    // Deployment's image PULL is performed by containerd on the node, using
+    // the node's own resolver, which has no route to *.svc.cluster.local at
+    // all — that namespace exists only in CoreDNS. This is the one place the
+    // project's "always use cluster DNS between services" rule cannot apply:
+    // the puller is not a service.
+    //
+    // It also has to be spelled identically everywhere, because Docker
+    // matches stored credentials and TLS trust by exact hostname: here, the
+    // dockerconfigjson auths key, Harbor's externalURL, and the node pool's
+    // CA trust config.
+    def image = "harbor.35.238.248.203.nip.io/${config.harbor_project}/${config.repo_name}:${tag}"
     try {
         stage(stageName('Build & push image')) {
             container('docker-cli') {

src/com/homelab/stages/updateHelmTag.groovy

@@ -16,7 +16,9 @@ package com.homelab.stages
 //   service_name      second path segment; same as repo_name for a
 //                     single-service repo, different for a monorepo with
 //                     several services sharing one repo
-//   helm_repo_url     e.g. http://gitea.192.168.1.7.nip.io/mukul/devops-helm-charts.git
+//   helm_repo_url     e.g. http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-helm-charts-gcp.git
+//                     (cluster DNS — this clone runs in a build pod, so it
+//                     never goes out through the ingress and back)
 //   image_tag_yq_path  yq path to the tag field, e.g. .deployment.image.tag
 //   gitea_cred        Jenkins credential ID for a Gitea push-capable token (default: gitea-ci-credentials)
 //