fix: support EKS member impersonation

[vgocoder]

Summary

• Avoid client-certificate CSR waits for imported token/exec kubeconfigs that can authenticate with the original credential and impersonate members instead.
• Preserve certificate-based member auth where CSR signing is available, while falling back to impersonation when a member binding has no certificate.
• Reuse the same impersonation-aware access setup across cluster access, proxy, and webkubectl config generation.

Why

Some managed Kubernetes services, including EKS, accept and approve kubernetes.io/kube-apiserver-client CSRs but do not populate status.certificate. KubePi currently waits for the certificate and returns a 500 after the CSR timeout when creating a cluster member.

Test Plan

• go test ./internal/api/v1/cluster ./internal/service/v1/clusteraccess ./internal/api/v1/proxy ./internal/api/v1/webkubectl

Manual Verification

• Reproduced on an EKS cluster: CSR became Approved with empty status.certificate.
• Verified patched KubePi creates an EKS cluster member in ~1s and the generated EKS RBAC allows the impersonated user to list namespaces.

[wanghe-fit2cloud]

@vgocoder

Thanks for the contribution. The overall direction of this PR makes sense, and it can address the issue where member creation times out when some clusters, such as EKS, approve the CSR but do not return a certificate.

However, the current implementation reuses the server-side impersonation configuration for the webkubectl kubeconfig download flow. Since webkubectl sends the generated kubeconfig to the member terminal, if that kubeconfig contains the original token or exec credentials used to import the cluster, a member could remove the impersonation fields and bypass KubePi's member RBAC restrictions.

I recommend separating the handling of server-side internal access from the webkubectl downloadable kubeconfig flow, and ensuring that original cluster credentials are not exposed to members before merging this PR.