spike: re-evaluate manifest-based admission control once prod runs Kubernetes 1.37 #4088

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

The trigger that the #3416 decision deferred to.

Not actionable until prod runs Kubernetes 1.37 or later. That is blocked by #3534, which in turn waits on the Talos 1.14 upgrade (#4044 / #3850). It is also worth re-checking earlier if Talos or KSail gain first-class support for supplying static admission manifests.

What to do then

Re-run the #3416 strong-fit gate against the then-current state, starting from that decision:

• Is there first-class Talos (or KSail) support for staticManifestsDir in the API-server admission configuration, or would it still need custom file, mount and argument plumbing?
• Is there a concrete admission resource whose unauthorized change or deletion matters enough to guard at the machine-config trust level? Evidence of tampering, or a named threat, is needed, since Flux already restores drifted resources.
• Is delivery and rollback across every control plane declarative and testable?

Acceptance criteria

• A recorded decision: adopt one narrow guard (with a follow-up delivery issue), defer again with a named trigger, or close as not planned.
• Versions and sources used are recorded.

Size: S (no delivery PR).