feat(k8s): Kustomize deployment kind — methods as providers (K4b)

[astrojerms]

K4(b) — deployment methods as providers

Adds a Kustomize kind to plugins/k8s, proving the K4(b) intent (and the K5 homelab-PaaS direction): a deployment method is just a provider/kind, alongside HelmRelease / Manifest / Argo — not bespoke platform code.

kind: Kustomize
spec:
  kubeconfigPath: { $ref: {...} }
  files:                         # in-memory kustomization tree
    kustomization.yaml: |
      namespace: guestbook
      namePrefix: gb-
      resources: [deployment.yaml, service.yaml]
    deployment.yaml: | ...

How

• spec.files (path → content) is an in-memory kustomization tree; renderKustomization builds it with sigs.k8s.io/kustomize/api (krusty over an in-memory filesystem — no temp dirs, no network) into object YAML. spec.path selects the build dir (default ., supports overlays).
• The rendered objects flow through the shared Manifest object-apply core: I factored applyObjectSet / getObjectSet out of applyManifest / getManifest (both kinds are "a set of applied cluster objects"), so a Kustomize is literally a Manifest whose content is computed. Delete/state are identical; manifestObserved gained a kind param.
• #Kustomize CUE schema; registered in Handshake + Apply/Get/Delete. examples/kustomize-app.yaml demonstrates it.

Dependency

kustomize/api was already an indirect dep (v0.18 → v0.21.1 upgrade), so the footprint change is modest — consistent with the plugin's existing helm/cli-runtime deps.

Scope

Flux and other methods follow the same pattern as future kinds — no framework change. This completes K4 (a + b).

Tests

renderKustomization (transforms applied, overlay build-dir, invalid-kustomization errors), spec.files parsing; the existing Manifest tests are unchanged (the shared core is intact).

Local CI (k8s plugin module): build, go test ./..., gofmt, vet, staticcheck, golangci-lint (0 issues), modernize — all green.