fix(ci): build with Kaniko instead of docker-in-docker

dind never actually came up on this runner regardless of how it was
addressed (unix socket, docker:2375, localhost:2375 all failed identically
after a successful registry login) — on GitLab's Kubernetes executor that
means the dind container needs `privileged: true` in the runner's own
config.toml, which is admin-side, not something this file can set.

Kaniko builds OCI images without any daemon, so it needs no privileged
pod and no dind service at all — GitLab's own recommended path for this
exact executor, and safer on a shared cluster besides.

.gitlab-ci.yml

@@ -89,44 +89,49 @@ verify:
     - npm run test:translations
     - npm run build
   # test:integration is deliberately NOT here — it spins up a real Stalwart
-  # fixture via docker-compose (Docker-in-Docker), heavier than a fast MR
-  # gate should be. Candidate for a separate scheduled job, not a blocker.
+  # fixture via docker-compose, which needs an actual Docker daemon this
+  # runner's Kubernetes executor doesn't provide without privileged mode
+  # (see the build job below). Candidate for a separate scheduled job on a
+  # differently-configured runner, not a blocker on every MR.
 
 # ---------------------------------------------------------------------------
 # build — push to dev only. Builds once; main never rebuilds (see header).
 # ---------------------------------------------------------------------------
 build:
   stage: build
-  image: docker:27-cli
-  services:
-    - docker:27-dind
+  # Kaniko builds OCI images without a Docker daemon, so it needs neither a
+  # dind service nor a privileged pod — GitLab's own recommended approach
+  # for the Kubernetes executor specifically. The docker:27-cli + dind
+  # combination that was here before this got as far as a successful
+  # $CI_REGISTRY login, then failed every way it was pointed
+  # (unix:///var/run/docker.sock, tcp://docker:2375, tcp://localhost:2375):
+  # the dind container itself was never actually listening, which on this
+  # executor means it needs `privileged: true` in the runner's own
+  # config.toml — a cluster/GitLab-admin setting outside this file's
+  # control. Kaniko sidesteps that requirement entirely rather than chasing
+  # runner permissions further, and is also the safer default on a shared
+  # cluster (no privileged containers at all).
+  image:
+    name: gcr.io/kaniko-project/executor:v1.23.2-debug
+    entrypoint: [""]
   rules:
     - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "dev"'
-  variables:
-    # docker:27-dind defaults to TLS on :2376 with certs under
-    # /certs/client, which this client image never mounts — the dind
-    # service comes up fine but the docker:27-cli image can't find it,
-    # surfacing as "Cannot connect to the Docker daemon at
-    # unix:///var/run/docker.sock" even though $CI_REGISTRY login already
-    # succeeded (that's a separate connection, straight to the registry,
-    # not through the daemon). DOCKER_TLS_CERTDIR="" disables that TLS
-    # requirement. Host is `localhost`, not the service alias `docker` —
-    # this runner uses GitLab's Kubernetes executor, where every container
-    # in a job shares one pod's network namespace, unlike the Docker
-    # executor's bridge network (where the service-name alias is how you'd
-    # reach it instead). Confirmed from the job log: pod names like
-    # runner-uncqet63-project-499-concurrent-* are Kubernetes-executor pods.
-    DOCKER_HOST: tcp://localhost:2375
-    DOCKER_TLS_CERTDIR: ""
-  before_script:
-    # $CI_REGISTRY / $CI_REGISTRY_USER / $CI_REGISTRY_PASSWORD are predefined
-    # GitLab CI variables — populated automatically now that this project's
-    # Container Registry is enabled. No CI/CD variable to create by hand.
-    - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
   script:
-    - docker build --build-arg GIT_COMMIT=$CI_COMMIT_SHA -t "$IMAGE:sha-$CI_COMMIT_SHORT_SHA" -t "$IMAGE:dev-latest" .
-    - docker push "$IMAGE:sha-$CI_COMMIT_SHORT_SHA"
-    - docker push "$IMAGE:dev-latest"
+    # $CI_REGISTRY / $CI_REGISTRY_USER / $CI_REGISTRY_PASSWORD are predefined
+    # GitLab CI variables, populated automatically now that this project's
+    # Container Registry is enabled — same credentials the old docker-login
+    # step already proved work, just handed to kaniko's own config.json
+    # instead of a daemon's.
+    - mkdir -p /kaniko/.docker
+    - |
+      echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$(printf '%s:%s' "$CI_REGISTRY_USER" "$CI_REGISTRY_PASSWORD" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
+    - >
+      /kaniko/executor
+      --context "$CI_PROJECT_DIR"
+      --dockerfile "$CI_PROJECT_DIR/Dockerfile"
+      --build-arg GIT_COMMIT=$CI_COMMIT_SHA
+      --destination "$IMAGE:sha-$CI_COMMIT_SHORT_SHA"
+      --destination "$IMAGE:dev-latest"
 
 # ---------------------------------------------------------------------------
 # bump-dev — no cluster access. Commits the just-built tag into the overlay