Use crictl to pull the images in parallel and optimize the download time

Currently `kubadm` pulls images and it takes around ~13 mins. We could use `crictl` to pull images in parallel and potentially optimize the download time.

```
provisioner@debian:/mnt/solo-weaver$ time sudo /opt/solo/weaver/sandbox/usr/local/bin/crictl pull registry.k8s.io/kube-controller-manager:v1.33.4
WARN[0000] Config "/etc/crictl.yaml" does not exist, trying next: "/opt/solo/weaver/sandbox/usr/local/bin/crictl.yaml"
Image is up to date for registry.k8s.io/kube-controller-manager@sha256:04125aa5788e68928262789588ac5829f4b44aa3eb1818500e70420fe480a69f

real 1m38.827s
user 0m0.008s
sys 0m0.016s
provisioner@debian:/mnt/solo-weaver$ time sudo /opt/solo/weaver/sandbox/usr/local/bin/crictl pull registry.k8s.io/kube-scheduler:v1.33.4
WARN[0000] Config "/etc/crictl.yaml" does not exist, trying next: "/opt/solo/weaver/sandbox/usr/local/bin/crictl.yaml"
Image is up to date for registry.k8s.io/kube-scheduler@sha256:b4edb982a5e739c805fbd1bfe63e47c61637ca5db0cf51c101c73c086dbbb96c

real 1m25.213s
user 0m0.010s
sys 0m0.012s
```

No file or test is named. Start by locating the kubeadm image-pull entry point and how it invokes crictl; identify the image list and current sequential flow. Done means the images are pulled in parallel through crictl, existing provisioning behavior remains intact, and the relevant tests or timing checks demonstrate the improved download path.

Written by the indexing model from the issue text.