fix(ci): pin the cluster CA in the repo rather than in a secret

The CA fingerprint is not a secret.  It is a public value that anyone can
read straight off the certificate, so pinning it in a Gitea secret was the
wrong shape:

- A change to it would be invisible - no commit, no review.
- Nobody with secret-write access could silently repoint the CI runner at a
  different CA.

It now lives in `scripts/cluster-ca.sha256`, so changing it is a reviewable
commit.  The script reads it from there, and still accepts an override as
its first argument.

This also removes the need for a `KUBE_SERVER_CA_FINGERPRINT` secret, which
the bot token cannot create anyway - the Actions secrets API is owner-only.

The behaviour is unchanged: the CA is fetched over an unverified connection
but only USED if it matches the pinned fingerprint, so an intercepted CA is
refused.  Re-tested against the live API server - the matching fingerprint
refreshes the CA and kubectl then works; a wrong one is refused and the
stale CA is left in place.

.gitea/workflows/build_push.yml

@@ -126,8 +126,9 @@ jobs:
           # The kubeconfig embeds the k3s server CA.  If the cluster's CA has
           # been rotated since the secret was created, kubectl cannot verify
           # the server.  The script refreshes the CA, but only if it matches
-          # the fingerprint pinned in the secret - see the script for why.
-          bash scripts/kube-ca-refresh.sh "${{ secrets.KUBE_SERVER_CA_FINGERPRINT }}"
+          # the fingerprint pinned in scripts/cluster-ca.sha256 - see the
+          # script for why.
+          bash scripts/kube-ca-refresh.sh
 
       - name: Install kubectl
         run: |