fix(migrations): pin KubeadmConfigTemplate on the 1.5 slot 45 migration and in the chart - #3892

Drives the pin end-to-end through the migration script, in the harness the
SeaweedFS half already uses: the real slot 45 executed by path inside the
migrations image's own pinned alpine base, so the interpreter under test
is the busybox ash that run-migrations.sh actually gives it, with only the
cluster boundary faked.

The property asserted is the annotation landing on the object, never a
function being callable. Thirteen cases: an unannotated Helm-managed
KubeadmConfigTemplate gets pinned and the slot stamps 46; several
templates are pinned each in its own namespace; an already-pinned one is
skipped WITHOUT a write; zero matching objects is a clean run; a
CAPI-spawned KubeadmConfig is left alone because it is not Helm-managed; a
cluster with no kubeadm bootstrap provider stamps cleanly; an object that
vanishes between the scan and the pin is skipped rather than fatal; a
failing fleet scan and a failed pin both abort without stamping; a partial
failure still pins the rest and then aborts; both halves run in one pass
with the SeaweedFS hand-over first; a SeaweedFS failure aborts before the
pin is attempted; and migration 43 does not pin, since the two libs must
stay independently sourceable.

The fake kubectl MODELS THE LABEL SELECTOR rather than ignoring it, which
is what makes the characteristic form of this bug detectable. Helm injects
app.kubernetes.io/managed-by=Helm as a LABEL; meta.helm.sh/release-name is
an ANNOTATION and can never be a selector, so using it matches nothing,
the pin silently applies to nothing, and the run reports pinned=0
failures=0 and exits 0. A fake that answered every selector identically
could not tell that apart from a working pin. An ABSENT selector lists
everything, exactly as kubectl does, so dropping the selector shows up as
the pin stamping keep on Machine-owned objects instead of as a quiet
no-op.

Also rewrites the nine pre-existing SeaweedFS "this did not happen"
assertions, which could not fail. POSIX and bash both exempt a !-negated
pipeline from errexit — "the -e setting shall be ignored ... if the
command's return value is being inverted with !" — so `! grep -q X f`
runs, returns 1, and the test carries on to report success. Measured in
this harness, not inferred: with the two halves of slot 45 deliberately
swapped, a `! grep -q 'PIN '` assertion stayed green while the command log
plainly contained the PIN line. The replacement,
[ "$(grep -c X f)" -eq 0 ], puts the result inside `[`, whose non-zero
status does trip errexit, and is the form already used elsewhere in the
file. Their claims turn out to have been true all along, so nothing about
the migrations changes; what changes is that they are now checked — with
the hand-over mutated to re-annotate a Cluster that already carries keep,
"idempotent: a Cluster already owned by <name>-db AND carrying keep is
left alone" now goes red where before it passed.

Every case was confirmed against a deliberately broken pin before being
made to pass: annotation-as-selector, no selector at all, best-effort
instead of fail-closed, an unconditional write instead of read-then-skip,
a vanished object treated as fatal, the halves swapped, and the pin never
called.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

Platform migration 45 pins the KubeadmConfigTemplate objects that exist
when a cluster runs it. That leaves a hole: a template created AFTERWARDS
— a new tenant Kubernetes cluster, or a nodeGroup added while on 1.5.4 —
is born without the annotation, and 1.6's own slot 45 never runs for that
cluster because a v1.5.4 cluster is stamped 46 and runs `seq 46 53`. The
1.6 kubernetes chart upgrade then prunes the unpinned template while the
kubeadm-backed MachineSet still references it from bootstrap.configRef,
which is the bug the migration exists to prevent.

Render the annotation in the chart so every template is born pinned. The
migration then covers only the objects that predate it, and the two
together leave no window.

KEEP IS SAFE ON THE UNINSTALL PATH, which is the only behaviour it
changes here. CAPI stamps an ownerReference to the Cluster on this object
— verified on a live v1.5 stand, where KubeadmConfigTemplate,
MachineDeployment and KubevirtMachineTemplate all carry
ownerReferences: [Cluster/<release>] that the chart itself does not
render — and the Cluster is Helm-managed with no keep of its own. So
`helm uninstall` deletes the Cluster and Kubernetes garbage collection
reclaims the template through that reference. keep suppresses Helm's own
delete; it has no bearing on owner-driven GC, so uninstall does not leak.

The name is deterministic, <release>-<nodeGroup>, not content-hashed the
way KubevirtMachineTemplate is, so keep cannot accumulate a copy per
upgrade. The one residue is a removed nodeGroup, whose template Helm no
longer prunes: it is inert because nothing references it, it is re-adopted
in place if that nodeGroup returns, and GC reclaims it with the Cluster.

Not added to KubeadmConfig: this chart renders no bare KubeadmConfig, and
the ones CAPI spawns from the template are owned by their Machine and
carry no app.kubernetes.io/managed-by label, so Helm never manages or
prunes them and the annotation would have nothing to act on. Confirmed on
the same live stand.

Nothing else in this chart sets helm.sh/resource-policy, so no existing
conditional is being overridden.

Tests assert the annotation on the rendered object for a single nodeGroup
and for every group when two are configured — the second because the
annotation has to sit inside the per-nodeGroup range, and a group added
later is exactly the one that would otherwise be left prunable. Both were
confirmed red before being made to pass: with the annotation removed from
the template they fail on `unknown path
metadata.annotations["helm.sh/resource-policy"]`, which is the object
being born unpinned rather than a broken assertion.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

…to fail

The four assertions in "neither chart classifies on mutable claim
timestamps or liveness" were written as `! grep -qF X "$f"`, which cannot
fail: POSIX and bash both exempt a !-negated pipeline from errexit — "the
-e setting shall be ignored ... if the command's return value is being
inverted with !" — so the command runs, returns 1, and the test carries on
reporting success. Those four were the entire body of the test, so it
asserted nothing whatsoever.

Converting them mechanically turns out to fail, and for a reason worth
keeping: all four names DO appear in both files, in the prose that
explains why each was rejected as a discriminator. `creationTimestamp` and
`readyReplicas` are discussed at length in the comment blocks that record
the decision. So a raw grep would fail on the documentation of the very
invariant the test enforces.

Assert against the template logic instead, with {{/* */}} comment blocks
stripped by a small awk helper. Every comment opener in both files starts
its own line, so dropping whole lines cannot take code with it. What the
test now forbids is a LIVE reference, which is what it always meant.

Proven in both directions: it passes with the explanatory prose in place,
and it fails when a real `readyReplicas` lookup is injected into live
template code in either file.

The awk helper is deliberately a one-liner. cozytest.sh rewrites any bare
`}` in column 0 into `return 0` + `}`, which would corrupt a multi-line
awk body.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>