fix(deps): siderolabs talos and machinery pins can skew, breaking the build #6734

🤖 Generated by the Agentic Engineer

Evidence

github.com/siderolabs/talos and github.com/siderolabs/talos/pkg/machinery are released together and
share the config API, but ksail pins them independently. On main both sit at v1.14.0-alpha.2.

Any bump that raises machinery alone breaks the build. Observed on #6724, where an omni/client
1.9.1 → 1.10.4 bump transitively raised machinery to v1.14.0-beta.1 and left talos at alpha.2:

pkg/fsutil/configmanager/talos/configs.go:615:54:
  cp.Machine().Kubelet undefined (MachineConfig has no field or method Kubelet)
pkg/fsutil/configmanager/talos/version.go:223:28: machineCfg.Kubelet undefined

.../talos@v1.14.0-alpha.2/pkg/images/list.go:43:49:
  config.Cluster().CoreDNS undefined (ClusterConfig has no field or method CoreDNS)

The last line is pinned Talos alpha.2 source failing against beta.1 machinery — proof the breakage is
the skew itself, not our call sites alone.

Why this recurs rather than being a one-off

machinery is an indirect dependency, so MVS treats it as a floor: any dependent that requires a newer
machinery raises it silently, with no corresponding change to the direct talos pin. Dependabot cannot
perform the coordinated two-module upgrade, so such a bump can arrive red and unmergeable. #6724 was
the historical instance and is now closed. Dependabot grouping shipped in #6803; the coordinated
target-version update is tracked by #6826.

Expected behaviour

The two siderolabs modules move together, and a transitive raise of one cannot silently skew them.

Acceptance criteria

• siderolabs/talos and siderolabs/talos/pkg/machinery are on the same version.
• Call sites adapted to the target config API — at minimum MachineConfig.Kubelet
  (pkg/fsutil/configmanager/talos/configs.go, version.go) and ClusterConfig.CoreDNS.
• The Talos CI legs pass.
• A guard prevents silent skew recurring: test(deps): name a talos/machinery version skew instead of failing inside talos #7199 added a module-version equality check that also
  rejects transitive machinery pseudo-version skew, while keeping the coordinated upgrade explicit.
• chore(deps): bump github.com/siderolabs/omni/client from 1.9.1 to 1.10.4 #6724 is closed; chore(deps): bump the talos group across 1 directory with 3 updates #6826 is the current coordinated update.

Remaining delivery

The current main branch pins both modules to v1.14.0-alpha.2; that does not prove the target-version
upgrade, adapted call sites, or passing Talos CI legs. Those criteria remain open with #6826 and its
Kubernetes SDK compatibility prerequisites, including #6728 and #7259.

Size: medium. The upgrade itself is small; the API migration and the anti-recurrence guard are the work.