spike(ci): install a docker CLI so the registry probe can get past login (#237)

The first run answered Question 1 with a flat no. The job container has no docker binary, so login died with exit 127 and the three steps that mattered were skipped — no answer on whether the registry accepts a push, and no build time.

What it did establish is that /var/run/docker.sock is mounted. The daemon is reachable; only the client is missing. That is a gap a step can close without reconfiguring the runner, so it is worth one more iteration before deciding anything.

The static binary rather than apt: one download, no package index to refresh, no repository to add, and only the CLI is wanted since the daemon already exists on the other side of that socket.

The architecture is resolved with uname rather than hardcoded. Nothing in this repository has ever confirmed what the NAS is, and assuming x86_64 would waste a whole run on the one machine everything else queues behind — the same class of mistake as assuming Portainer's build context contained .git in #235.

This step is deliberately not continue-on-error, unlike the diagnostics above it. If the client cannot be installed there is nothing left to measure, and one clear failure reads better than three skipped steps.

Still workflow_dispatch only, still bounded by timeout-minutes, still deleted when #237 is answered.

Ref #237

.gitea/workflows/spike-registry.yml

@@ -54,6 +54,37 @@ jobs:
           echo "--- disk ---"
           df -h / | tail -1
 
+      # Iteration 2. The first run answered Question 1 with "no": the job
+      # container has no `docker` binary and login died with exit 127. What it
+      # also showed is that /var/run/docker.sock IS mounted, so the daemon is
+      # reachable and only the client is missing — which is a gap this step can
+      # close without changing how the runner itself is configured.
+      #
+      # The static binary rather than apt: it is one download with no package
+      # index to refresh and no repository to add, and only the CLI is wanted.
+      # The daemon already exists on the other side of that socket.
+      #
+      # Not continue-on-error. If this fails there is nothing left to measure,
+      # and a clear failure here is more useful than three skipped steps.
+      - name: Install the docker CLI, since the runner has none
+        run: |
+          DOCKER_VERSION=27.3.1
+          # Resolved rather than assumed. The NAS's architecture has never been
+          # confirmed anywhere in this repository, and hardcoding x86_64 would
+          # waste a whole run on a machine that everything else queues behind.
+          case "$(uname -m)" in
+            x86_64)          DOCKER_ARCH=x86_64 ;;
+            aarch64|arm64)   DOCKER_ARCH=aarch64 ;;
+            *) echo "unsupported architecture $(uname -m) — no static docker build for it"; exit 1 ;;
+          esac
+          echo "runner architecture: $(uname -m) -> downloading $DOCKER_ARCH"
+          curl -fsSL "https://download.docker.com/linux/static/stable/${DOCKER_ARCH}/docker-${DOCKER_VERSION}.tgz" -o /tmp/docker.tgz
+          tar -xzf /tmp/docker.tgz -C /tmp
+          install -m 0755 /tmp/docker/docker /usr/local/bin/docker
+          docker version
+          echo "--- can it reach the daemon through the socket? ---"
+          docker info --format 'server {{.ServerVersion}}, {{.Driver}}, {{.Architecture}}'
+
       # Reported as a boolean, never printed. If this says NO, the login below
       # will fail and the fix is to add the secret, not to change the workflow.
       - name: Is a token available?