Kubernetes version is not updated in shared mode

During the validation of #465 we have found a small issue related to the version shown with kubectl get nodes:

@enrichman I have a created a cluster with a host cluster with 4 nodes 3 server and 1 agent and created a virtual cluster with 1 node using version v1.32.10-k3s1. I see the following issues,

1. Even though i have passed servers as 1, I see 4 nodes created.
2. For the first update to v1.32.11, I have patched the cluster and with kubectl version I see the version is updated but does not reflect while running kubectl get nodes
3. Similar behaviour is see while using update

k3kcli cluster create --version v1.32.10-k3s1 --servers 1 --mode shared shared1
INFO[0000] Creating namespace 'k3k-shared1'             
INFO[0000] Creating cluster 'shared1' in namespace 'k3k-shared1' 
INFO[0001] Cluster details:
  Mode: shared
  Servers: 1
  Version: v1.32.10-k3s1 (Host: v1.32.10)
  Persistence:
    Type: dynamic
    Size: 2G 
INFO[0001] Waiting for cluster to be available..        
INFO[0076] Extracting Kubeconfig for 'shared1' cluster  
INFO[0076] certificate CN=system:admin,O=system:masters signed by CN=k3s-client-ca@1770964940: notBefore=2026-02-13 05:42:20 +0000 UTC notAfter=2027-02-13 06:43:25 +0000 UTC 
INFO[0076] You can start using the cluster with:

	export KUBECONFIG=/home/ec2-user/k3k-shared1-shared1-kubeconfig.yaml
	kubectl cluster-info

Patching the cluster

ec2-user@ip-172-31-17-228:~> kubectl patch clusters.k3k.io -n k3k-shared1 shared1 --type=merge --patch '{"spec": {"version":"v1.32.11-k3s1"}}'
cluster.k3k.io/shared1 patched

kubectl version reflects the update

ec2-user@ip-172-31-17-228:~> kubectl version
Client Version: v1.32.10+k3s1
Kustomize Version: v5.5.0
Server Version: v1.32.11+k3s1

Nodes (with incorrect count) shows original version that is v1.32.10

ec2-user@ip-172-31-17-228:~> export KUBECONFIG=/home/ec2-user/k3k-shared1-shared1-kubeconfig.yaml
ec2-user@ip-172-31-17-228:~> 
ec2-user@ip-172-31-17-228:~> kubectl get nodes
NAME                                          STATUS   ROLES   AGE   VERSION
ip-172-31-17-228.us-east-2.compute.internal   Ready    agent   84s   v1.32.10-k3s1
ip-172-31-22-171.us-east-2.compute.internal   Ready    agent   84s   v1.32.10-k3s1
ip-172-31-26-157.us-east-2.compute.internal   Ready    agent   86s   v1.32.10-k3s1
ip-172-31-28-90.us-east-2.compute.internal    Ready    agent   83s   v1.32.10-k3s1

Updating to v1.33.0

ec2-user@ip-172-31-17-228:~> k3kcli cluster update --version v1.33.0-k3s1 shared1 --namespace k3k-shared1
INFO[0000] Updating cluster 'shared1' in namespace 'k3k-shared1' 
Version: v1.32.11-k3s1 -> v1.33.0-k3s1

New Cluster details:
  Mode: shared
  Servers: 1
  Version: v1.33.0-k3s1 (Host: v1.32.10)
  Persistence:
    Type: dynamic
    Size: 2G

Do you want to update the cluster? [y/N]: y

INFO[0004] Cluster updated successfully   

kubectl version reflects the updated version while kubectl get nodes returns original version

ec2-user@ip-172-31-17-228:~> kubectl version
Client Version: v1.32.10+k3s1
Kustomize Version: v5.5.0
Server Version: v1.33.0+k3s1

ec2-user@ip-172-31-17-228:~> kubectl get nodes
NAME                                          STATUS   ROLES   AGE   VERSION
ip-172-31-17-228.us-east-2.compute.internal   Ready    agent   19m   v1.32.10-k3s1
ip-172-31-22-171.us-east-2.compute.internal   Ready    agent   19m   v1.32.10-k3s1
ip-172-31-26-157.us-east-2.compute.internal   Ready    agent   19m   v1.32.10-k3s1
ip-172-31-28-90.us-east-2.compute.internal    Ready    agent   18m   v1.32.10-k3s1
ec2-user@ip-172-31-17-228:~> kubectl get pods -A
NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE
kube-system   coredns-697968c856-hwtzv   1/1     Running   0          7m38s
ec2-user@ip-172-31-17-228:~> 

Originally posted by @ShylajaDevadiga in #465

As written in the original issue this is because the virtual kubelet gets some information at startup, and those are not being updated.

We have a goroutine that is currently polling the nodes to get updated info related to the node resources, but we are not checking for anything else. We probably should.