feat(kubernetes): bootstrap tenant workers with Talos via CABPT - #2610

The test script (tests/containerd-config-path-test.sh) plus its two
toml fixtures (tests/fixtures/containerd-{1x,2x}.toml) guarded a pair
of sed lines that lived inside the kubeadm-era KubeadmConfigTemplate's
preKubeadmCommands. That whole block disappeared when the chart
switched to TalosConfigTemplate — there are no preKubeadmCommands in
the Talos worker bootstrap path, containerd is configured by Talos
itself via its machineconfig dialect (machine.files / machine.kubelet
extraConfig), not by post-boot shell sed.

After this PR the script's grep -qF against the template fails with
`sed line drifted` because the strings it's looking for are simply
gone, taking down the chart's `make test` and the repo-level
`helm-unit-tests` CI step.

Remove the script, its Makefile invocation, and the now-orphan
fixtures directory. If a Talos-equivalent containerd assertion is
desired later it belongs in helm unittest against the rendered
machineconfig blob, not as a regex check on cluster.yaml.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

The image-talos-csr-signer target still used the legacy `$(call settag,
...)` helper, which was removed from hack/common-envs.mk in main and
replaced by the `$(call image-tags, <repo>, <versioned-tag>)` macro
used by every other image-* target in this Makefile. After rebasing
onto current main the unresolved `settag` call expands to an empty
string, so the build emits `--tag <REGISTRY>/talos-csr-signer:` with
nothing after the colon and docker buildx rejects it with
`invalid reference format`. CI Build job exits 1.

Re-aligning with image-cluster-autoscaler / image-kubevirt-csi-driver
which already use image-tags. The follow-up `echo` line that pins the
digest into images/talos-csr-signer.tag now references $(IMAGE_TAG)
directly, matching the same convention.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…idecar boot

The e2e fixture's `kubectl wait` budgets were tuned to the pre-Talos
Kamaji cold-start (3-4 minutes for kube-apiserver+controller-manager+
scheduler+konnectivity). After this PR the apiserver pod additionally
pulls and starts the talos-csr-signer sidecar, and cert-manager must
issue three Talos PKI Certificates (talos-ca, talos-tls-cert, plus the
Kamaji-issued ca) before the wait-for-kubeconfig init container clears.
Cold-start in a fresh CI sandbox (no warm image cache) consistently
crosses the old 4m/5m budgets and the test fails at
`kubectl wait tcp ... --timeout=5m` with
`error: timed out waiting for the condition on tenantcontrolplanes/<name>`.

Raise both `TenantControlPlaneCreated` and `tcp ... version.status=Ready`
budgets to 10m, matching the `release.cozystack.io/helm-install-timeout: 15m`
that cozystack-api stamps onto every Kubernetes tenant HR. Downstream
waits (`deploy --timeout=4m`, `machinedeployment --timeout=1m`) are
unaffected by Talos PKI work and keep their tighter budgets.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…admission accepts the unmodified install

The MachineHealthCheck CRD's `spec.maxUnhealthy` is an IntOrString. The
CAPI admission webhook accepts either a bare integer ("0", "1", ...) or
a percentage ("0%", "50%") but rejects a bare numeric string with:

    admission webhook "validation.machinehealthcheck.cluster.x-k8s.io"
    denied the request: MachineHealthCheck ... is invalid:
    spec.maxUnhealthy: Invalid value: intstr.IntOrString{...,
    StrVal:"0"}: must be either an int or a percentage:
    invalid value for IntOrString: invalid type: string is not a
    percentage

The previous default ("0", a string without a percent sign) hit exactly
that path and caused Helm install to fail on every fresh tenant
Kubernetes install — surfaced by the e2e suite's
`Create a tenant Kubernetes control plane with latest version` step,
which then dropped the chart (cascade-deleted KamajiControlPlane) and
the downstream wait never had anything to find.

"0%" is semantically identical (any unhealthy node triggers remediation
immediately) and passes admission. Custom values like "50%" or bare
integers like "1" continue to work; the field stays parametric for
operators that want to relax remediation during a kubeadm-to-Talos
rollover.

Regenerated values.schema.json, README.md, types.go, and the
kubernetes-rd cozyrds OpenAPI schema via the chart's `make generate`.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

PR review on this branch flagged that the previous default ("0" string)
was still wrong even after the values.yaml default flip: any operator
that overrides nodeHealthCheck.maxUnhealthy to a bare integer (e.g. "1",
which is also a valid IntOrString) gets the same admission rejection,
because `| quote` unconditionally wraps the rendered value in quotes
and the MHC webhook treats "1" as a non-percentage string.

Render conditionally: if the supplied value has a `%` suffix, keep the
existing quoted-string form (percentages must be strings). Otherwise,
render as a bare integer via the Sprig `int` function — that handles
the chart-default "0%", the now-safe "0", and any operator override
like "1" or "5" all in one path.

Follow-up to PR review:
cozystack#2610 (comment)

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

… Helm template into post-install hook Job

Chart used Helm `lookup` to gate the TalosConfigTemplate (TCT) and to
fold the apiserver Service ClusterIP into KamajiControlPlane's
network.certSANs. Both inputs — the Service, the Talos-CA TLS Secret,
the Kamaji-issued tenant CA Secret — only exist AFTER Helm applies the
first render: Kamaji controller emits the Service in reaction to the
KamajiControlPlane CR this same chart applies, cert-manager issues the
Talos PKI from the Certificate CR this same chart applies, and Kamaji
generates the tenant CA as part of its bootstrap. On a fresh tenant
install all three lookups return nil on first render, $talosReady is
false, TCT is skipped, and the certSANs list omits the ClusterIP.

Helm 3's release-storage three-way merge then refuses to upgrade
because no values changed. The lookups become valid 30s later, but
nothing requests a re-render. The MachineDeployment.bootstrap.configRef
points at a TalosConfigTemplate that never lands, so CAPI's
MachineDeployment controller emits `cannot create a new MachineSet
when templates do not exist` forever. The apiserver TLS cert is
generated by Kamaji without the live ClusterIP in its SAN list, so
even if a worker were to boot, its kubelet would reject the apiserver
on `x509: certificate is valid for <DNS> not <IP>`.

Suspend+resume and values-drift tricks force a second render manually
but every fresh install hits the same race; that's not a chart-level
fix, it's a workaround the operator has to remember on every tenant.

Move both objects into a post-install/post-upgrade Helm hook Job
(templates/talos/talos-reconcile-job.yaml) that:
  - waits up to ~10m for Service.spec.clusterIP, <release>-talos-ca,
    <release>-ca to be observable;
  - JSON-merge-patches KamajiControlPlane.spec.network.certSANs to
    include the live ClusterIP plus the two Service DNS names (Kamaji
    re-issues the apiserver TLS cert in response);
  - reads stable random tokens from <release>-talos-secrets (chart-self
    rendered, always present at hook time);
  - kubectl applies the TalosConfigTemplate with the full machineconfig
    inlined and an ownerReference to the KamajiControlPlane.

The owner reference lets the Kubernetes garbage collector reap the TCT
when the chart's KCP is deleted on `helm uninstall`; no pre-delete
hook needed. The Job runs at hook-weight 5, between the chart's
post-install resources and the bootstrap-token-tenant-job at weight 10,
so the bootstrap-token Secret lands inside the tenant kube-system only
after the worker machineconfig that consumes it is in place.

cluster.yaml drops the lookup gates ($apiSvc / $apiSvcIP /
$talosSecrets / $talosCA / $k8sCA / $talosReady / $talosToken /
$clusterId / $clusterSecret / $bootstrapToken / $talosCACrt /
$k8sCACrt / $apiEndpoint) and the gated TCT block. The certSANs list
on the KamajiControlPlane keeps only the two DNS entries; the
ClusterIP arrives via the hook.

The e2e fixture (hack/e2e-apps/run-kubernetes.sh) waits 5m instead of
1m for `machinedeployment ... status.replicas=2` so the
post-install-hook + Talos image pull + first VM boot fit in budget on
a cold sandbox.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

… reservations

The post-install hook Job is the new home of the TalosConfigTemplate
authorship (replacing the lookup-and-reuse pattern). On any cozystack
tenant the default-deny CiliumClusterwideNetworkPolicy on the release
namespace blocks the hook pod from reaching the management apiserver
to read the Service ClusterIP / Talos CA / k8s CA / KamajiControlPlane
it has to reconcile, leaving the Job stuck in a wait loop and the
release pending-install.

Ship a CiliumNetworkPolicy alongside the hook that allows egress to
the kube-apiserver entity (and kube-dns for name resolution) for pods
labelled cozystack.io/talos-reconcile=<release>. Cilium policies are
additive, so the tenant default-deny stays in force for everything
else in the namespace.

Inline the kubelet-reservation computation from cluster.yaml directly
in the hook template; the previous helper reference was unresolved at
render time and aborted the chart. Numbers match cluster.yaml's
auto-computed system/kube reserved memory (5% of effective memory
clamped to 256Mi..1Gi) and CPU (5% clamped to 50m..500m).

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…hook

The Talos PKI Certificate that secures the trustd / apid sidecar
endpoint at https://<Service ClusterIP>:50001 used the same
lookup-and-reuse pattern as the TalosConfigTemplate the previous fix
already moved out into the post-install hook. On a fresh install the
Service ClusterIP does not yet exist when the chart renders, the
lookup returns nil, and the Certificate is issued with only the
DNS-name SANs. Workers then fail TLS to apid with "cannot validate
certificate for <ClusterIP> because it doesn't contain any IP SANs"
and stall at "service apid to be up".

Drop the lookup gate from talos-pki.yaml and add a second
kubectl patch step to the talos-reconcile hook Job that writes
spec.ipAddresses on <release>-talos-tls-cert once the Service is
live. cert-manager reissues the cert with the new SAN, the worker's
TLS handshake succeeds, and apid comes up.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…los worker migration

Seven distinct issues found during cozy-review and end-to-end testing
on a dev cluster. Bundled here as a single squashed commit:

* nodeHealthCheck.maxUnhealthy default 0% -> 50%.
  Talos workers boot in pulls from factory.talos.dev that exceed the
  10m nodeStartupTimeout on slow networks. With the prior 0% default a
  single Machine briefly NotReady triggers MHC remediation, CAPI spawns
  a replacement that also boots slowly, and the cluster loops. 50%
  leaves room for transient unhealthy nodes during the kubeadm-to-Talos
  rollover; drop back to 0% in a follow-up once fleets stabilise.

* bootstrap-token Job backoffLimit 5 -> 10.
  Aligns the Job's worst-case wall time (~15m under exponential backoff
  capped at 6m per retry) with the chart's HR install timeout
  (release.cozystack.io/helm-install-timeout: 15m). At backoffLimit=5
  the Job could exhaust retries before the tenant apiserver came up on
  a slow cluster, failing the chart upgrade silently.

* migration 44 (v1.30 -> v1.31) surfaces per-tenant failures.
  Tracks failed (ns, name) pairs and writes them to a
  cozystack.io/migration-44-failed-tenants annotation on the
  cozystack-version ConfigMap. Operators previously had to grep Job
  logs because the migration exits 0 (intentional, for retry) and the
  Job status stays green while individual tenants are stuck at v1.30.

* talos-reconcile-job memory limit 64Mi -> 256Mi.
  Reproduced OOMKill on dev3: pod completed the wait loop and the
  KamajiControlPlane / Certificate JSON-merge patches, then died at
  the kubectl-apply that pipes a TalosConfigTemplate manifest. Fresh
  installs survive the 64Mi limit because kubectl's working set is
  smaller against an empty cluster; upgrades on established tenants
  pay the merge-and-diff cost. 256Mi leaves headroom for the embedded
  JSON marshalling and discovery cache.

* Talos workers reach the apiserver via DNS instead of the live
  ClusterIP. The post-install hook previously patched the Talos PKI
  Certificate to add the apiserver Service ClusterIP as an IP SAN.
  cert-manager reissues the Secret but the csr-signer sidecar loads
  its TLS cert once at startup and does not watch the file, so on a
  fresh install it keeps serving the original (no-IP-SAN) cert.
  Talos apid then fails the trustd TLS handshake with 'x509: cannot
  validate certificate for <IP> because it does not contain any IP
  SANs' and the worker boot stalls on 'service apid to be up'
  indefinitely. Drop the certificate patch and route Talos workers
  to the apiserver via <release>.<namespace>.svc. The Talos
  machineconfig now sets cluster.controlPlane.endpoint to the DNS
  form and seeds machine.network.extraHostEntries with the live
  ClusterIP, so worker /etc/hosts resolves the name without depending
  on tenant CoreDNS (which is itself bootstrapped after Cilium, which
  dials this same endpoint). The Talos PKI Certificate already carries
  DNS SANs from chart render time so TLS verification succeeds against
  the chart-issued cert with no race. Cilium's k8sServiceHost can also
  drop the lookup-and-reuse fallback and use plain DNS.

* CABPT controller-manager runs under a uniquely-named ServiceAccount.
  The vendored CABPT components manifest uses the implicit 'default'
  SA in cabpt-system. cluster-api operator copies the manifest and
  rewrites every {kind: ServiceAccount, name: default, namespace:
  cabpt-system} subject to point at the BootstrapProvider's own
  namespace (cozy-cluster-api). The Deployment still runs as
  cabpt-system/default, the controller has no RBAC and CrashLoops on
  'cannot list resource ... at the cluster scope'. TalosConfigs never
  reconcile and Machines stay forever in WaitingForBootstrapData. The
  kubeadm bootstrap provider in the same chart works because it uses
  a uniquely-named SA the operator leaves alone. Mirror that pattern
  for CABPT: ServiceAccount cabpt-manager in cabpt-system, wire all
  four (Cluster)RoleBindings to it, and set the Deployment's
  serviceAccountName accordingly. Regenerated components-talos.gz
  from the edited source.

* Drop the GPU node-label test obsoleted by the Talos worker switch.
  Main added a test asserting GPU node-groups register their nodes
  with gpu=on via KubeadmConfigTemplate.spec.template.spec.joinConfiguration.nodeRegistration.kubeletExtraArgs.node-labels.
  After this PR, KubeadmConfigTemplate is replaced by
  TalosConfigTemplate rendered out-of-band by the talos-reconcile
  hook and the chart no longer carries the kubelet args the test
  inspects. The GPU labeling feature itself is not yet wired up on
  Talos workers in this Phase 1 (group.gpus still attaches GPU
  devices to the VM but nothing sets gpu=on on the resulting node).
  Tracking as a Phase 1 regression rather than restoring the
  now-irrelevant kubeadm-shaped assertion.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…olver

Tenant Kubernetes workers in main run as Ubuntu+kubeadm KubeVirt VMs
and inherit pod DNS via cloud-init, so they resolve management-cluster
services (NFS endpoints used by kubevirt-csi like
linstor-csi-nfs.cozy-linstor.svc) out of the box. Talos workers in this
PR are strict and consult only what is in machineconfig; with no host
resolver wired up, kubelet's NFS mount syscall fails with NXDOMAIN
when kubevirt-csi-backed PVCs are mounted.

The reconcile hook now looks up the management CoreDNS Service ClusterIP
at runtime and injects it into machine.network.nameservers in the
TalosConfigTemplate. Tenant in-cluster pods are unaffected: they use
kubelet --cluster-dns (tenant CoreDNS) via dnsPolicy: ClusterFirst.
This nameserver only covers host-side paths (mounts, image pulls,
pods that opt out of cluster DNS), which is what main provided via
cloud-init.

Adds a narrow ClusterRole + ClusterRoleBinding scoped to
resourceNames: ["kube-dns"] so the hook ServiceAccount can read the
single well-known Service without broader cluster-scoped privilege.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

Follows cozystack#2855. The talos-csr-signer image target was added on this
branch before cozystack#2855 merged, so the rebase brought it in still
pointing --cache-from at $(REGISTRY)/talos-csr-signer:latest, which
on PR CI is the per-CI registry where :latest is never published.
That cache lookup 404s on every PR build and forces a cold rebuild,
exactly the failure mode cozystack#2855 fixed for the other Makefiles.

Aligns the only remaining $(REGISTRY)-targeted --cache-from with the
$(CACHE_REGISTRY) ghcr.io convention from cozystack#2855 so PR builds of this
target warm-start off the last release's :latest.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…ittest

The old KubeadmConfigTemplate set kubeletExtraArgs.node-labels="gpu=on"
for nodeGroups carrying .gpus; the Talos machineconfig the post-install
hook applies had no machine.nodeLabels at all. HAMi's hami-device-plugin
DaemonSet selects nodes via nvidiaNodeSelector: gpu: "on", so on Talos
workers the plugin stayed at DESIRED=0 and no nvidia.com/* resources
were advertised — a functional regression for every GPU tenant flagged
in PR review.

Adds machine.nodeLabels: {gpu: "on"} into the TalosConfigTemplate
emitted by templates/talos/talos-reconcile-job.yaml, gated on
$group.gpus to match main's per-group conditional. The inline comment
points the next reader at the HAMi selector so the contract is obvious.

Restores tests/gpu_node_labels_test.yaml — adapted from the deleted
KubeadmConfigTemplate-targeted version to assert on the rendered post-
install Job script via matchRegex (the TCT itself is not rendered by
helm; the hook applies it at runtime), covering both the "has gpus -->
labeled" and "no gpus --> no nodeLabels" paths.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…apped regression

PR review flagged that `templates/copy-patch-containerd.yaml` still
copies the cozy-system/patch-containerd Secret into the tenant namespace
but its only consumer — the containerd certs.d mount in the deleted
kubeadm template — went away with the Talos rollover. The Talos
machineconfig the post-install hook applies has no machine.registries
block, no installer override, and the worker boot image is fetched
by CDI over HTTPS directly from factory.talos.dev. The chart-shipped
copy of the patch-containerd Secret is therefore unreferenced cruft
and the platform-wide registries.mirrors feature no longer reaches
tenant workers at all.

Phase 1 of the Talos migration is scoped to the rollover itself;
restoring air-gapped/mirror support for tenant workers via
machine.registries.mirrors (and matching imageBase/installerImage
override knobs) is non-trivial — containerd certs.d format does not
translate 1:1 to the Talos registries schema — and is deferred to a
follow-up. Drops the orphan template, removes the misleading
"air-gapped mirrors of factory.talos.dev" hint from the
nodeStartupTimeout doc (operators reading that today would assume
mirrors work — they do not), and adds an explicit Breaking Changes
entry to the chart README so air-gapped operators see this regression
before they upgrade rather than after a failed worker boot.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

PR review flagged three spots where dead code accumulated as the
branch iterated on the post-install hook design:

(1) cluster.yaml: $kubeletVersion / $talosVersion / $talosSchematic
were defined at the top of the per-loop template after the TCT was
moved into talos-reconcile-job.yaml — the hook redefines them in its
own context and the cluster.yaml block referenced none of them.

(2) talos-reconcile-job.yaml: the cert-manager.io/certificates get +
patch RBAC was added when the hook patched the Talos PKI Certificate's
spec.ipAddresses to include the apiserver Service ClusterIP. That
approach was dropped in favour of routing workers through the apiserver
Service DNS name (with extraHostEntries injecting the ClusterIP into
the worker /etc/hosts), which sidesteps the TLS race against the csr-
signer sidecar entirely. The RBAC grant is now unused and the hook is
now strictly Talos-scoped — narrowing it removes an unnecessary
cluster-write-adjacent grant for the hook ServiceAccount.

(3) bootstrap-token-tenant-job.yaml: TENANT_KUBECONFIG env var was a
holdover from an earlier design that distinguished the kubectl
kubeconfig from a tenant-only handle; the current script reads only
$KUBECONFIG (which already points at the same path), so the second
variable was unreferenced.

No behavioural change — the chart renders identically and helm-unittest
suite stays green.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

… Talos rollover

PR review flagged that values.yaml and the generated README/CRD still
describe the pre-Talos disk layout. The kubernetes chart used to
provision a separate disk-kubelet PVC for kubelet/containerd state;
the Talos worker boots from a single system disk imaged from the
factory artifact and the chart no longer renders disk-kubelet at all.

- values.yaml: diskSize description now covers the consolidated single
  system disk (Talos OS image + kubelet state + containerd image cache
  + local-path PVCs) instead of the pre-Talos "kubelet and containerd
  data" wording.
- values.yaml: nodeHealthCheck.nodeStartupTimeout no longer hints at
  air-gapped mirrors of factory.talos.dev — Phase 1 has no
  machine.registries.mirrors plumbing, so the hint was promising
  behaviour the chart does not deliver (called out separately in the
  README Breaking Changes section).
- README.md: migration-41 paragraph rewritten so the persistence model
  reflects the single Talos system disk rather than the removed
  disk-kubelet layout.
- Regenerated values.schema.json, api/apps/v1alpha1/kubernetes/types.go,
  and packages/system/kubernetes-rd/cozyrds/kubernetes.yaml via
  `make generate` so the chart, Go API, and tenant CRD all carry the
  same description.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…efile tagging

PR review flagged that the Dockerfile comment claimed images are mirrored
into ghcr.io/cozystack/cozystack/talos-csr-signer:<commit>, but the
Makefile (image-tags macro) actually tags by chart version
(KUBERNETES_PKG_TAG / IMAGE_TAG) and writes the resulting <digest> into
images/talos-csr-signer.tag. The upstream commit is fingerprinted
indirectly via the digest, not via the tag itself.

Comment-only change in Dockerfile. The images/talos-csr-signer.tag file
itself still pins the upstream ghcr.io/clastix/...:latest digest and
must be regenerated by running `make image-talos-csr-signer` in
packages/apps/kubernetes/ (with REGISTRY=ghcr.io/cozystack/cozystack)
before release — that step needs ghcr.io/cozystack/cozystack push
access, which only the release pipeline / maintainer holds, so the
regeneration is left to the merge handoff rather than baked into
this PR.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

PR review flagged six load-bearing comments that no longer matched
reality after the chart converged on the post-install-hook design and
the cozyrds helm-install-timeout was bumped 15m -> 20m:

- _helpers.tpl: wait-for-kubeconfig deadline rationale referenced the
  15m install timeout. The cozyrds entry now carries 20m
  (release.cozystack.io/helm-install-timeout) — updated, with the
  source of truth (cozyrds annotation) called out so the next reader
  finds the canonical value.
- bootstrap-token-tenant-job.yaml: backoffLimit budget rationale
  likewise referenced 15m; the worst-case ~15m attempt window stays,
  it just now sits well inside the 20m HR window instead of right at
  the edge.
- hack/e2e-apps/run-kubernetes.sh: comment above kubectl wait
  referenced the 15m alignment; corrected to 20m.
- tests/cluster_test.yaml header: described a "$talosReady gate" that
  hid the TalosConfigTemplate document, which no longer exists — the
  TCT is produced at runtime by the talos-reconcile post-install
  hook, not by cluster.yaml. Rewritten to describe the actual document
  order the test asserts on.
- tests/kubelet_reservation_test.yaml header: same $talosReady
  reference + a now-stale note about "happy-path TCT assertions not
  ported"; updated to point at gpu_node_labels_test.yaml as the
  in-repo example of how to assert on the hook's command literal.
- templates/cluster.yaml: a "Hoist all lookups" block described an
  optimisation that no longer applies — the lookups moved into the
  talos-reconcile hook so cluster.yaml has nothing to hoist any more.
  Removed.

No executable code changed; helm unittest stays at 89 PASS.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…+ new talos templates + MHC + support-matrix

PR review flagged that new code paths landed without tests. This commit
closes the gap:

- pkg/config/config_test.go: table test for the new
  ParseHelmInstallDisableWaitAnnotation parser, mirroring the sibling
  ParseHelmInstallTimeoutAnnotation test that already pinned that
  function's behaviour. cozystack-api reads the annotation on every
  ApplicationDefinition at startup and a typo here silently flips the
  parent kubernetes HR into "wait for child HRs", reproducing the
  Phase 1 install deadlock the disable-wait annotation was added to
  break. 11 sub-cases cover empty / true / True / TRUE / false / False
  / FALSE / mixed-case (invalid) / integer (invalid) / yes (invalid) /
  garbage (invalid).
- tests/talos_templates_test.yaml: renders + key-field assertions on
  the four new talos/* templates (bootstrap-token-tenant-job,
  talos-pki, talos-reconcile-job, talos-secrets) so a future refactor
  breaking ServiceAccount/Role/CRB wiring is caught locally before
  push. Uses documentIndex constants tied to source-file order with
  comments noting the layout.
- tests/mhc_rendering_test.yaml: pins the MHC maxUnhealthy int-vs-
  percent rendering branch — the CAPI admission webhook rejects a
  quoted plain integer ("0") so the chart strips the quote when no
  percent suffix is present, and the test exercises both arms.
- tests/talos_k8s_support_matrix_test.yaml: happy-path coverage for
  the $talosK8sSupportMatrix guard. Failure-path coverage is left as
  a follow-up — values.schema.json's Version enum is strictly tighter
  than the matrix window right now, so the fail() branch is
  unreachable from the test harness until either side relaxes.

Total: 11 new Go subtests + 8 new helm-unittest tests; suite goes 87
-> 97 passing.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>

…rovider's pattern

PR review flagged that capi-providers-bootstrap had no update target
documenting how files/bootstrap-components-talos.yaml and
files/components-talos.gz were produced — the cabpt-manager
ServiceAccount rename was hand-applied to a vendored bundle and the
process was undocumented, blocking reproducible bumps of
CABPT_UPSTREAM_VERSION. The sibling capi-providers-cpprovider package
already has a working update target; this commit mirrors that pattern
so both packages have symmetric maintenance flow.

- Makefile: new `update` phony target that downloads the
  CABPT_UPSTREAM_VERSION release artifact from siderolabs/cluster-api-
  bootstrap-provider-talos, applies patches/, writes the result to
  files/bootstrap-components-talos.yaml, and regenerates the gzip
  bundle. CABPT_UPSTREAM_VERSION is the single bump knob; the comment
  block points at the two other call-sites (BootstrapProvider
  spec.version + the clusterctl ConfigMap name) so the next operator
  bumping versions can keep them in lockstep without grepping.
- patches/0001-rename-default-sa-to-cabpt-manager.diff: the
  cozystack-side patch that replaces upstream's default ServiceAccount
  references with cabpt-manager, captured as a unified diff so
  `patch(1)` can re-apply it deterministically on top of any future
  CABPT_UPSTREAM_VERSION. Without the rename, capi-operator rewrites
  the SA namespace (`default` is the SA's literal name in upstream and
  capi-operator treats that as the default SA needing rewrite) and the
  CABPT Deployment loses its RBAC — see PR cozystack#2610 for the original
  diagnosis.
- files/components-talos.gz: regenerated via the new target using
  `gzip -n` so the bundle is byte-reproducible (no embedded mtime or
  filename), making future `make update` runs idempotent. Decompressed
  content is identical to the previous file.

Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>