Reach the builder instead of starting one

Both image jobs died at builder init:

  dial unix /var/run/docker.sock: connect: no such file or directory

A job here runs in an ephemeral pod that has the docker CLI and no daemon, so
`driver: docker-container` has nothing to start a builder in and QEMU has
nothing to register with. That is the shape of the runner, not a fault in it.

The cluster already runs buildkit as a DaemonSet, one node per architecture,
behind a service. So the builder is reached rather than started, and the
emulation question goes away with it: each node builds its own platform
natively, which is also faster than the QEMU path this replaces.

.github/workflows/release.yml

@@ -63,16 +63,20 @@ jobs:
     steps:
       - uses: actions/checkout@v4
 
-      - name: Set up QEMU
-        if: matrix.arch == 'arm64'
-        uses: docker/setup-qemu-action@v3
-        with:
-          platforms: arm64
-
+      # NO DOCKER DAEMON HERE, and that is the shape of a runner rather than a
+      # fault: a job runs in an ephemeral pod with the docker CLI and no socket,
+      # so `docker-container` cannot start a builder and QEMU cannot be
+      # installed. Measured: both image jobs died at builder init with
+      # `dial unix /var/run/docker.sock: no such file or directory`.
+      #
+      # The cluster already runs buildkit — a DaemonSet with one node per
+      # architecture behind buildkitd-node:1234 — so the builder is reached
+      # rather than started, and the emulation question goes with it: each node
+      # builds its own platform natively.
       - uses: docker/setup-buildx-action@v3
         with:
-          driver: docker-container
-          driver-opts: network=host
+          driver: remote
+          endpoint: tcp://buildkitd-node.hanzo-build.svc.cluster.local:1234
 
       - uses: docker/login-action@v3
         with: