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.

scripts/cluster-ca.sha256

@@ -0,0 +1,17 @@
+# SHA-256 fingerprint of the cluster's API server CA (the k3s server-ca.crt).
+#
+# This is a PUBLIC value, not a secret - it can be read straight off the
+# certificate.  It lives in the repo rather than in a Gitea secret so that
+# changing it is a reviewable commit, and so nobody with secret-write access
+# can silently repoint the CI runner at a different CA.
+#
+# The deploy job fetches the cluster's CA over an unverified connection and
+# compares its fingerprint against this value.  A CA that does not match is
+# refused, so an attacker able to intercept the fetch cannot substitute
+# their own.
+#
+# To refresh it after a legitimate CA rotation:
+#   openssl x509 -in /var/lib/rancher/k3s/server/tls/server-ca.crt #     -noout -fingerprint -sha256
+# and update the line below (colons are stripped before comparison, so either
+# format works).
+d23a17bb9c5f7c66d15e15635d6bb928e3a34f38142705e4e6516075a5f35907