[BUG] Imported EKS IPv6 clusters do not sync ipFamily from upstream

Rancher Server Setup Rancher version: v2.15.1 Installation option (Docker install/Helm Chart): Helm Chart If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): 2.15.1 / 110.0.1+up11.0.2 Proxy/Cert Details: N/A

Information about the Cluster Kubernetes version: 1.36 Cluster Type (Local/Downstream): Downstream If downstream, what type of cluster? AWS EKS (imported)

User Information What is the role of the user logged in? Admin If custom, define the set of permissions: N/A

Describe the bug When importing (registering) an existing EKS cluster into Rancher, the cluster's ipFamily is not brought in from the upstream EKS cluster. The eks-operator correctly reads ipFamily from AWS and stores it on status.eksStatus.upstreamSpec.ipFamily, but the value is never propagated to spec.eksConfig.ipFamily, so it remains empty on the imported cluster's config.

To Reproduce Create an EKS cluster in AWS (e.g. one created with ipFamily: ipv6, though any EKS cluster shows the gap). Import/register the cluster into Rancher as a AWS EKS cluster. Wait for the upstream refresh to run and the cluster to reach active state. Inspect the cluster's eksConfig via the API or the EKSClusterConfig resource, and compare against status.eksStatus.upstreamSpec.

Because there is no ipFamily, the eks-operator cannot reconcile the publicAccessSources as the test in the operator [in filterPublicAccessSources()]depends on spec.eksConfig.ipFamily, which is perpetually missing.

Result spec.eksConfig.ipFamily is empty/unset on the imported cluster, even though the upstream EKS cluster reports a value and status.eksStatus.upstreamSpec.ipFamily is populated. Cluster update attempts fail because AWS returns errors reporting the requested config update already matches the existing settings.

Expected Result spec.eksConfig.ipFamily reflects the upstream EKS cluster's ipFamily. Since ipFamily is immutable in EKS (set at creation and cannot be changed), the upstream value is always authoritative and should be stored on the cluster config.

Additional context Root cause appears to be in the upstream-to-spec sync in cluster_upstream_refresher.go. The sync only copies an upstream field into spec.eksConfig when that field is already set on the spec:

for key, value := range upstreamSpecMap {
    if specMap[key] == nil {
        continue   // ipFamily is nil on a freshly imported cluster, so it is skipped
    }
    ...
}

For an imported cluster, eksConfig.ipFamily starts out nil. Because the field is omitempty, it is absent from specMap, the == nil guard skips it, and the upstream value is never written to the spec. Most other EKS fields (region, subnets, version, serviceRole, etc.) are populated during import, so they pass the guard; ipFamily is the field that falls through.

Notes: Specific to ipFamily. EKS service CIDR (serviceIpv4Cidr/serviceIpv6Cidr) is not modeled in EKSClusterConfigSpec and is not used by Rancher today, so it is not affected. The eks-operator side correctly detects and stores ipFamily in the upstream spec; the gap is on the Rancher spec-sync step. EKS ipFamily immutability reference: https://docs.aws.amazon.com/eks/latest/APIReference/API_KubernetesNetworkConfigRequest.html Workaround: manually set spec.eksConfig.ipFamily on the imported cluster to match the upstream value.