k0s workers are not using private IP address to access the k8s API server

### Before creating an issue, make sure you've checked the following:

- [x] You are running the latest released version of k0s
- [x] Make sure you've searched for existing issues, both open and closed
- [x] Make sure you've searched for PRs too, a fix might've been merged already
- [x] You're looking at docs for the released version, "main" branch docs are usually ahead of released versions.

### Platform

```shell
Ubuntu 24.04.3 LTS
```

### Version

v1.33.8+k0s.1

### Sysinfo

`k0s sysinfo`

➡️ Please replace this text with the output of `k0s sysinfo`. ⬅️

### What happened?

k0sctl is using public IP address to connect to the control plane.

```yaml
apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s-cluster
user: admin
spec:
k0s:
version: v1.33.8+k0s.1
config:
apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
metadata:
name: my-k0s-cluster
namespace: kube-system
hosts:
- role: controller+worker
ssh:
address: CP_1_PUBLIC_IPV4
user: root
port: 22
privateInterface: enp7s0
- role: worker
ssh:
address: WORKER_1_PUBLIC_IPV4
user: root
port: 22
privateInterface: enp7s0
- role: worker
ssh:
address: WORKER_2_PUBLIC_IPV4
user: root
port: 22
privateInterface: enp7s0
- role: worker
ssh:
address: WORKER_3_PUBLIC_IPV4
user: root
port: 22
privateInterface: enp7s0
```

### Steps to reproduce

1. `k0sctl apply --config k0sctl.yaml`
2. Fail
3.

### Expected behavior

Servers have public and private IP addresses. I assume the intent of defining the `privateInterface` and/or `privateAddress` is to use the private network for Kubernetes communication.

### Actual behavior

But `k0sctl` is still trying to use the public network and failing because firewall is configured for the private interfaces.

### Screenshots and logs

```
INFO ==> Running phase: Install workers
INFO [ssh] CP_1_PUBLIC_IPV4:22: generating a join token for worker 1
INFO [ssh] CP_1_PUBLIC_IPV4:22: generating a join token for worker 2
INFO [ssh] CP_1_PUBLIC_IPV4:22: generating a join token for worker 3
INFO [ssh] WORKER_1_PUBLIC_IPV4:22: validating api connection to https://CP_1_PUBLIC_IPV4:6443 using join token
INFO [ssh] WORKER_3_PUBLIC_IPV4:22: validating api connection to https://CP_1_PUBLIC_IPV4:6443 using join token
INFO [ssh] WORKER_2_PUBLIC_IPV4:22: validating api connection to https://CP_1_PUBLIC_IPV4:6443 using join token
INFO * Running clean-up for phase: Acquire exclusive host lock
INFO * Running clean-up for phase: Install workers
INFO [ssh] WORKER_1_PUBLIC_IPV4:22: cleaning up
INFO [ssh] WORKER_2_PUBLIC_IPV4:22: cleaning up
INFO [ssh] WORKER_3_PUBLIC_IPV4:22: cleaning up
INFO ==> Apply failed
FATA apply failed - log file saved to /Users/user/Library/Caches/k0sctl/k0sctl.log: failed on 3 hosts:
- [ssh] WORKER_3_PUBLIC_IPV4:22: connectivity check failed: context deadline exceeded
failed to connect to kubernetes api using the join token - check networking: command failed: client exec: ssh session wait: Process exited with status 1
- [ssh] WORKER_1_PUBLIC_IPV4:22: connectivity check failed: context deadline exceeded
failed to connect to kubernetes api using the join token - check networking: command failed: client exec: ssh session wait: Process exited with status 1
- [ssh] WORKER_2_PUBLIC_IPV4:22: connectivity check failed: context deadline exceeded
failed to connect to kubernetes api using the join token - check networking: command failed: client exec: ssh session wait: Process exited with status 1
```

### Additional context

_No response_

Start by tracing the k0sctl apply workflow through the “Install workers” phase, especially join-token API validation and how privateInterface or privateAddress is used. Reproduce the failure with the supplied configuration and verify that worker-to-control-plane Kubernetes API traffic uses the private network rather than the public address.

Written by the indexing model from the issue text.