fix(platform): make etcd v1alpha2 adoption (migration 50) robust in-cluster - #3258

What this PR does

Fixes two defects in platform migration 50 (etcd etcd.aenix.io → etcd-operator.cozystack.io/v1alpha2 adoption, #2859) that block every in-cluster 1.5 → 1.6 upgrade on a cluster with an existing etcd:

1. Cert-SAN wait treated transient kubectl failures as "SAN absent." ensure_wildcard_sans checked/awaited the wildcard SAN with kubectl get … 2>/dev/null | grep; any transient GET failure (API discovery refresh, apiserver blip, throttling) yields an empty string indistinguishable from a genuine absence → false miss, and the 120s wait never recovers. Replaced the two checks with a _san_present helper that retries on an empty read (a real Certificate/Secret never has empty dnsNames/alt-names) and accepts the native wildcard from either the issued Secret's cert-manager.io/alt-names annotation or the Certificate spec.dnsNames. This is the deeper root cause behind etcd v1alpha2 adoption migration hard-fails 1.5→1.6 upgrade on clusters with an existing etcd #3243's "cert re-issue race (times out a few seconds too early)".

2. etcd-migrate had no kubeconfig in-cluster (etcd v1alpha2 adoption (migration 50): etcd-migrate has no kubeconfig in-cluster → adoption aborts #3255). etcd-migrate only reads a kubeconfig file (-k/--kubeconfig, default /root/.kube/config) and, unlike kubectl, does not fall back to the mounted in-cluster ServiceAccount. Neither the hook Job nor the script provided one, so both the dry-run and --apply aborted with error building kubeconfig: stat /root/.kube/config: no such file. Now the script synthesizes an in-cluster kubeconfig from the mounted ServiceAccount and passes --kubeconfig to both etcd-migrate calls.

Scope is limited to packages/core/platform/images/migrations/migrations/50 (a shell script — no make generate artifacts affected).

Verification

Verified end-to-end on a real 1.5.2 → 1.6.0-rc.1 upgrade (3-node cluster): with these fixes the pre-upgrade hook passes the cert step reliably and etcd-migrate runs, so the adoption completes in-place (etcd pods never restarted, data intact) and the adopted EtcdCluster reaches readyMembers=3 / Available=True.

Note: a couple of adjacent adoption-completion blockers were found in the same run and reported separately — see #3255, #3256, and the follow-up comment on #3243 (etcd-operator memory floor / OOM, and the legacy etcd-headless Service being pruned mid-transition so per-pod DNS breaks). They live outside migrations/50 and are not part of this PR.

fix(platform): etcd v1alpha2 adoption migration is now robust in-cluster — the cert-SAN wait no longer mis-reads a transient kubectl failure as a missing SAN, and `etcd-migrate` is given an in-cluster kubeconfig so the adoption runs to completion.