fix: discover Kubernetes issuer for kubectl-ate

[yashrajshuklaaa]

Fixes the hardcoded Kubernetes issuer in setup/CI by discovering the issuer from the cluster’s OIDC config.
This fixes kubectl-ate auth on kind.

Fixes #2763

[supreme-gg-gg]

One minor comment. I ran into this multiple times with kubectl-ate locally and fixed it similarly, so this should be the correct fix

[EItanya]

This makes sense if we're doing generic setup, but this is part of a CI setup that always installs into kind, so how would this come up?

[yashrajshuklaaa]

@EItanya yeah, CI uses kind but that’s actually where the mismatch shows up.
kind advertises https://kubernetes.default.svc.cluster.local while we were hardcoding https://kubernetes.default.svc.
Reading the issuer from the cluster avoids making that assumption.

[EItanya]

@EItanya yeah, CI uses kind but that’s actually where the mismatch shows up. kind advertises https://kubernetes.default.svc.cluster.local while we were hardcoding https://kubernetes.default.svc. Reading the issuer from the cluster avoids making that assumption.

But then wouldn't it be failing?

[yashrajshuklaaa]

@EItanya yeah, CI uses kind but that’s actually where the mismatch shows up. kind advertises https://kubernetes.default.svc.cluster.local while we were hardcoding https://kubernetes.default.svc. Reading the issuer from the cluster avoids making that assumption.

But then wouldn't it be failing?

@EItanya I checked and CI doesn't actually hit the code path this fixes. admin commands (make-ca-pool, make-jwt-pool) auth through the kubeconfig context directly, not through ate-api's JWT check. So the issuer in the configmap never gets validated during CI setup. mismatch only shows up on stuff like kubectl-ate get actor-template which sends a real bearer token to ate-api for validation. that's the exact command failing in #2763. CI just never runs anything like that so it stays green either way.

Could add a CI step that runs a kubectl-ate get after setup to catch this going forward, if that's useful. Can do it here or separate PR.

[EItanya]

CI isn't running on this PR for some reason and I can't approve without that. Can you either:

1. remove the ci.yaml change. (It might only let maintainers edit workflows)
2. add a very small other change just to run CI