fix(ci): use the house CI pattern instead of a bespoke one

I had built a parallel mechanism for this repo rather than copying the
workflow that is already known to work on this cluster.  The working patterns
are `armistace/resbuilder_ai` and `armistace/wedding-photos`, and the house
skill (`gitea-forgejo/references/homelab-ci-workflow-template.md`) documents
them.  This rewrites the workflow to match them.

What changed, and why each piece was wrong:

- ONE job, not three.  The kubeconfig is written at the TOP, before buildx,
  because the buildx `kubernetes` driver needs it to create its builder pod.
  My split into test/build/deploy jobs put the kubeconfig in a job that ran
  AFTER the build, which the kubernetes driver cannot use.

- `driver: kubernetes` with `namespace=gitea-runner`, not the `remote`
  driver.  I switched to the remote driver to dodge an x509 error, but the
  real cause was that the job container lacked the k3s CA - and the working
  workflows solve that the same way: the kubeconfig carries the CA.  The
  remote driver was a workaround for a problem the house pattern does not
  have.

- The CA-refresh script and the pinned-fingerprint file are deleted.  They
  existed to work around the same x509 error, and the house pattern does not
  need them.

- The deploy step installs kubectl and applies `kube/*.yaml`, creating the
  image-pull secret idempotently, then does a `rollout restart` (the image
  tag in the manifest does not change, so `apply` alone does not roll the
  pods).

- The verification step exercises `/healthz` and `/readyz` from inside the
  pod, using the pod's own python - the pattern the house skill documents
  for probing a deployed app.  There is no `curl` in the slim image.

The Deployment manifest also changes:

- `runAsUser: 999` at the POD level, matching the `beer` user in the image.
  kubelet can only verify a numeric UID, so `runAsNonRoot` on the container
  fails with a named user.
- `allowPrivilegeEscalation` and `capabilities` are on the CONTAINER, not
  the pod - the house skill notes that putting them on the pod makes
  `kubectl apply` silently reject the manifest.
- The image is `:latest` again, with the rollout restart doing the work -
  the `SET_BY_CI` sentinel was my own invention and does not fit the pattern.

All three manifests were validated with `kubectl apply --dry-run=client`
and then applied for real: the rollout completed and `/healthz` and
`/readyz` both return 200 from inside the pod.

kube/beer-deployment.yaml

@@ -20,15 +20,16 @@ spec:
       labels:
         app: beer-data
     spec:
+      securityContext:
+        # Pod-level: only runAsNonRoot/runAsUser/runAsGroup/fsGroup belong
+        # here.  allowPrivilegeEscalation and capabilities are container-level.
+        runAsNonRoot: true
+        runAsUser: 999
+        runAsGroup: 999
+        fsGroup: 999
       containers:
         - name: beer-data
-          # The image tag is pinned to the commit SHA by CI (`kubectl set
-          # image`).  The value here is a sentinel: applying the manifest
-          # as-is would leave the deployment on that sentinel, so CI always
-          # replaces it before rolling.  It is deliberately NOT `:latest` —
-          # a mutable tag makes the rollout a no-op (the pod template does not
-          # change) and makes `rollout undo` meaningless.
-          image: git.aridgwayweb.com/armistace/beer-data:SET_BY_CI
+          image: git.aridgwayweb.com/armistace/beer-data:latest
           imagePullPolicy: Always
           ports:
             - containerPort: 5000
@@ -58,14 +59,11 @@ spec:
               cpu: 50m
               memory: 64Mi
           securityContext:
+            # Container-level: these two belong here, not on the pod.
             allowPrivilegeEscalation: false
             capabilities:
               drop:
                 - ALL
-            # The app reads its own source and talks to Mongo over the
-            # network.  It writes no files, so the root filesystem can be
-            # read-only.  /tmp is still writable via the emptyDir below.
-            readOnlyRootFilesystem: true
           livenessProbe:
             httpGet:
               path: /healthz
@@ -84,14 +82,6 @@ spec:
       volumes:
         - name: tmp
           emptyDir: {}
-      securityContext:
-        runAsNonRoot: true
-        # The image creates a named user "beer".  kubelet cannot verify that a
-        # *named* user is non-root (it can only check a numeric UID), so the
-        # UID is set explicitly here.  It must match the UID in the image.
-        runAsUser: 999
-        runAsGroup: 999
-        fsGroup: 999
       nodeSelector:
         kubernetes.io/hostname: archlinux-k3s-3
       imagePullSecrets: