fix(kubernetes): give the worker-adoption guard a remedy an operator can run - #3903

Migration 54 deliberately skips hostile stored shapes -- an over-long
child release name, an RFC-1123-invalid nodeGroups key, a non-object
group value or nodeGroups map, a non-scalar scalar field -- by pinning
the pool's worker objects with helm.sh/resource-policy=keep and moving
on, so one tenant's mangled HelmRelease cannot deadlock the platform
pre-upgrade hook for every tenant.

Until now the only trace of that decision was a WARNING on the hook Job's
log, and the Job carries helm.sh/hook-delete-policy:
before-hook-creation, so the next platform upgrade deletes it. A pool
left pinned-but-unadopted was then invisible: prune-proof, unmanaged,
and named nowhere an operator could look afterwards.

pin_pool_objects now appends "<cluster>/<group>" to a temp file and the
end of the script turns a non-empty file into the ConfigMap
cozystack-migration-54-unadopted. A file rather than a shell counter
because pin_pool_objects is only ever reached from inside the
per-cluster and per-group pipeline subshells, whose variables die with
them, while the emit point sits outside both `done`s. Hooked on
pin_pool_objects only -- pin_cluster_pools delegates to it, so
instrumenting both would double-count -- and above its invalid-name
early return, so a slash-bearing key that cannot name any object is
recorded too.

The record is diagnostic, not platform state, so it deliberately does
NOT carry platform.cozystack.io/no-delete: an operator who has acted on
it may delete it. And its apply is deliberately non-fatal: under
set -euo pipefail a failed apply would exit before the stamp and re-run
the whole adoption for every tenant over a bookkeeping write, so it
warns instead. adopt_one's foreign-owner refusal stays out of the
record -- it pins one object while the rest of the pool still adopts, so
listing the pool as unadopted would mislead.

The new bats case drives the 53-char overflow branch and asserts the
ConfigMap was applied under its own name, parses as YAML, and lists
exactly that one pool. Its red phase was checked both ways: with the
record removed it fails, and with the record emitted but the pool half
of each line dropped it also fails.

The fake kubectl now discriminates an applied manifest on its own kind
instead of on the word appearing anywhere in it. The record's note text
names "HelmRelease", and the substring match sent it down the child-HR
branch, where it was rejected as an HR with an empty metadata.name --
found by the new case on its first run. It also splits the version stamp
from any other ConfigMap so the record cannot masquerade as a stamp, and
writes the record's body to FAKE_APPLIED_CM so a test can assert which
pools it lists.

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

… child_values

The bad_scalar guard type-checks the fields child_values copies out of
the per-group nodeGroups value, so a stored object where a scalar belongs
routes into the warn + pin + skip contract instead of fabricating a child
HelmRelease that cannot validate. Nothing says that the cluster-level
half of the same construction gets no such check, and the next reader
hits the guard before the fallbacks.

Record it where they will look: storageClass and
nodeHealthCheck.maxUnhealthy / nodeStartupTimeout are unvalidated and
fire only when the per-group key is absent, while the version/talos pick
is unconditional and therefore reaches every pool. A non-scalar stored
there is copied through, the child HelmRelease lands, and it fails
KubernetesNodes schema validation naming the offending field in its own
status.

Deliberately left as a disclosure rather than a sixth skip branch. A
check here would convert a legible child-HR failure into "pinned,
unmanaged, warning in a Job log the next upgrade deletes", and since
migration 54 stamps unconditionally that silent outcome would be
once-only. Loud there beats silent here. Comment only, no behaviour
change.

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