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.