[k8s] Extract K8s commands into a ContainerK8s library target

[jshi991]

Feature or enhancement request details

Summary

Extract all K8s logic out of the container-k8s plugin executable and into a new ContainerK8s library target. The plugin binary in Sources/Plugins/K8s/ becomes a thin entry point that calls K8sCommand.main(). No behavior changes are expected

---

Background

Currently all K8s logic — commands, kubeadm provisioning, kubeconfig management, cluster helpers — lives directly inside the container-k8s plugin executable target. This makes it impossible for other targets to import and extend K8s commands without forking the binary. A library extraction gives K8s a clean, importable surface while keeping the plugin pattern intact.

---

Changes

1. New Sources/ContainerK8s/ library

Move all Swift source files from Sources/Plugins/K8s/ (except the entry point) into Sources/ContainerK8s/. File names and contents are unchanged.

Sources/ContainerK8s/
├── Commands/
├── K8sCommand.swift
├── K8sCreate.swift
├── K8sDelete.swift
├── K8sList.swift
├── K8sLoadImage.swift
├── K8sStart.swift
└── K8sWriteConfig.swift
├── K8sHelper.swift
├── KubeConfig.swift
└── Resources/
└── kindnet.yaml

All types used by the entry point must be public.

2. Sources/Plugins/K8s/ becomes a thin entry point

Only the entry point Swift file and config.toml remain:

Sources/Plugins/K8s/
├── config.toml (unchanged)
└── K8sMain.swift

3. Package.swift

Add the new library target and update the plugin executable to depend on it:

---

Acceptance criteria

• swift build succeeds
• container k8s create, start, delete, list, load-image, write-config behave identically
• Sources/Plugins/K8s/ contains only config.toml and the entry point file
• ContainerK8s compiles independently of the plugin target
• ContainerK8s has no dependency on targets unrelated to K8s (e.g. ContainerBuild, ContainerXPC)

Code of Conduct

• I agree to follow this project's Code of Conduct