chore: bump Go to 1.25.8 and fix CI and gosec issues

[maxlambrecht]

What

• Bump the minimum Go version to 1.25.8 in go.mod, add the unreleased changelog entry, and align the Makefile toolchain version with that minimum.
• Update golangci-lint to v2.11.4 and fix the Makefile Go download URLs to use the full Go version so Windows CI can fetch the toolchain correctly.
• Move SPIFFE TLS peer authorization from VerifyPeerCertificate to VerifyConnection in spiffetls/tlsconfig, and update related tests and smaller gosec-driven example/test cleanups.

Why

• Keep the repository’s minimum supported Go version aligned with its support policy.
• Make the lint/toolchain setup work with the newer Go target and restore Windows CI toolchain downloads.
• Ensure custom SPIFFE TLS authorization also runs on resumed sessions, which VerifyPeerCertificate alone does not cover.

How tested

• make lint
• make test

[azdagron]

Thanks for this, @maxlambrecht! I have some backcompat concerns that I'm not sure how to resolve right away...

[azdagron]

I'm worried about backwards compatibility. There are two situations:

1. somebody passes a tls.Config where either VeriyPeerCertificate/VerifyConnection is set. This code handles that fine.
2. somebody takes the returned tls.Config and wraps VerifyPeerCertificate. We'd break the latter here, because we no longer set VerifyPeerCertificate.

I need to think about how we handle this. Open to suggestions. It may be the case that we have to accept a small breaking change. In any case, whatever we pick, the nuances should be documented on the functions.

[maxlambrecht]

Good point. The implementation already preserves the input-side case by capturing any existing config.VerifyPeerCertificate / config.VerifyConnection callbacks and invoking them after SPIFFE auth succeeds. The remaining change is the narrow returned-config case: callers that previously wrapped VerifyPeerCertificate on the returned config now need to extend VerifyConnection instead, since SPIFFE auth has to live on VerifyConnection to also run on resumed sessions. I updated the function docs to call out that nuance explicitly, and I added focused tests for the preserved input-callback behavior and chaining/error propagation. So this is a narrow breaking change, but I think it is the right tradeoff here.