feat(controller): guarded repo-wide prune for git-as-source (homelab B2)

[astrojerms]

Roadmap target B2. Makes the repo the desired SET, not just an additive source: after a pull, resources whose manifest file was removed from the repo are deleted. Opt-in via manifests.gitops.pull.prune (default OFF — this deletes real infrastructure).

Safety-first design

manifests.Pruner is deliberately conservative — every path errs toward NOT deleting:

• File still on disk → never a candidate (present = still desired).
• Composite children are skipped. Checks both the generic owner labels (openctl.io/owner-kind/name) and the operative k3s.openctl.io/cluster label. The live Cluster.Apply path tags a cluster's VMs with the latter, not owner labels — checking only one scheme would orphan-delete a running cluster's VMs. Deleting the parent composite cascades to its children instead.
• Hand-managed resources are protected. A resource whose latest successful apply was cli/ui-sourced is skipped. Provenance comes from the operations table (there's no source column on applied_manifests). Unknown provenance (GC'd ops) is treated as prunable — so the feature keeps working after op GC — but the child guard still applies.

Wired after Watcher.Sync in the pull loop; deletes go through the same gitops-sourced Delete-op path as deleteOnRemove.

Why these guards matter (from a safety audit)

• applied_manifests has no source column → provenance must come from the ops table, and may be GC'd.
• Startup Reconcile re-materializes missing files — but prune runs in the pull loop and deletes the store row, so a re-materialize can't revive a pruned resource.
• The operative k3s path does not set owner labels — hence the dual label check.

Tests

Every guard branch: file-present keep, gitops/unknown-provenance prune, cli-source skip, both child-label schemes skip, and nil-source-lookup still guards children.

Next: B3 (GitHub/PR flow).