k3s: keep the listen port with the runtime disk

[somaz94]

Refs #1595

When a stopped instance is deleted without --data, the runtime disk keeps /var/lib/rancher, but the k3s listen port only lives in /etc/colima/colima.json on the root disk. The next colima start picks a new random port, while the kubeconfigs k3s generated under /var/lib/rancher/k3s/server/cred still point at the old one. k3s then restarts in a loop with controller-manager exited ... connect: connection refused, which is what juliantibble traced in the issue. Deleting a running instance does not hit this, because the teardown runs k3s-uninstall.sh and the k3s state goes with it.

This change records the port in the instance store, which is kept and reset together with the runtime disk, and reuses it when the VM is recreated on a formatted disk. An existing instance records its port on its next start, so an instance that is already in the broken state still needs colima delete --data.

Testing

Test_getPortNumber covers reusing the stored port, storing the port read from the VM, and ignoring a stored port when there is no formatted disk. All three fail without the change. go test ./... passes with Go 1.26.1, and golangci-lint v2.11.3 reports no issues for darwin and linux.

I also reproduced it on macOS 14 (Apple Silicon, vz, containerd, k3s v1.35.0+k3s1). On main, colima stop, colima delete and colima start left k3s listening on a new port with the cred kubeconfigs on the old one, and it restarted 4 times in the first 8 minutes. With this change, the same sequence on an instance first created by main kept the port and the existing cluster, and k3s did not restart.

AI disclosure: all of the code and tests in this PR were written with Claude Code (Claude Opus 5.5), and the checks above were run through it. I reviewed the whole diff before opening this PR.