The talos-reconcile Job runs under a 256Mi limit and applies its
TalosConfigTemplate client-side. Building the merge patch means pulling
the cluster's full OpenAPI schema down, which on a management cluster
carrying a few hundred CRDs costs around 290Mi of RSS, so the kernel
OOMKills kubectl before the Job can finish.

Only the merge path pays that cost. The first run creates the object and
stays cheap, so a fresh install succeeds and the Job then
CrashLoopBackOffs on every reconcile afterwards, which means on every
chart upgrade. Measured against a 438-CRD cluster with the Job's own
kubectl (alpine/k8s:1.33.4), cold discovery cache:

  get -o jsonpath                    52Mi
  apply, object absent (create)      52Mi
  apply, object present (merge)     292Mi   <- OOMKilled at 256Mi
  apply --server-side                56Mi

--validate=false changes nothing, so the cost is the merge strategy
lookup rather than validation.

Server-side apply leaves the merge to the apiserver and the client never
needs the schema. --force-conflicts keeps the Job authoritative over an
object an earlier client-side apply created.

Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <[email protected]>
(cherry picked from commit 1728b49)