feat(deps): update siderolabs/talos ( v1.13.10 ➔ v1.14.1 )

[mortyops]

This PR contains the following updates:

Package	Update	Change
siderolabs/talos	minor	v1.13.10 → v1.14.1

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[github-actions]

⚠️ Automated recommendation: REQUEST CHANGES

Analysis engine: pr-review-local@http://litellm.ai.svc.cluster.local:4000/v1 (openai)

Recommendation

Request Changes. This PR proposes a Talos minor version upgrade from v1.13.10 to v1.14.1. While the diff itself is a standard Renovate bump, the repository standards explicitly flag Talos upgrades as high-risk due to the TalosUpgrade CR and the allowedVersions pin in .renovate/overrides.json5. The standards state: "Flag a bare <X.Y.Z form here as a regression - once the tracked value passes such a ceiling it silently blocks every future Talos proposal."

Before merging, the operator must verify that the allowedVersions pin in .renovate/overrides.json5 does not contain a ceiling that would block v1.14.x or that the pin has been updated to allow this major/minor jump. If the pin is a ceiling (e.g., <1.14.0), this PR will fail Renovate's next run or be blocked by the pin. If the pin is an exclusion list (e.g., !=1.13.3), it is likely fine, but this must be confirmed.

Additionally, the standards note: "A PR touching these is a proposal, not a deployment - flag any claim that merging applies it." This PR does not apply the config, but the operator must manually run just talos apply-node or just talos upgrade-node after merge, and verify cluster health node-by-node.

Change-by-Change Findings

talos/machineconfig.yaml.j2

• Change: Updates installer image from v1.13.10 to v1.14.1.
• Risk: Minor version upgrade. Talos upgrades require manual intervention (just talos upgrade-node) and rolling reboots.
• Verification Needed: Check .renovate/overrides.json5 for allowedVersions pin. If it contains a ceiling like <1.14.0, it must be removed or updated to <1.15.0 (or similar) to allow this upgrade. If it only excludes v1.13.3, it is safe.
• Standards Compliance: The standards require that allowedVersions pins are not ceilings that block future upgrades. If this PR is merged without updating the pin, future Renovate PRs for Talos may be blocked or auto-merged incorrectly if the pin is removed.

Standards Compliance

• Talos Pins: The standards explicitly warn about allowedVersions ceilings in .renovate/overrides.json5. This PR does not change that file, so the operator must verify the pin is compatible with v1.14.1.
• Manual Apply: The standards state that merging this PR does not apply the config. The operator must manually apply it.
• No Secrets: No secrets are present in the diff.
• Renovate: The PR is generated by Renovate and follows the standard format.

Tool Harness Findings

Tool harness is disabled.

Unknowns or Needs Verification

1. allowedVersions Pin: Does .renovate/overrides.json5 contain a ceiling that blocks v1.14.x? If so, this PR must be accompanied by a pin update, or it will be blocked by Renovate.
2. Talos v1.14 Compatibility: Are there any known breaking changes in Talos v1.14 that affect this cluster's configuration (e.g., kernel modules, Cilium compatibility)? The standards mention that tuppr drives upgrades, so verify that tuppr is configured to allow v1.14.
3. Rolling Upgrade Plan: The operator must have a plan to upgrade nodes one at a time, ensuring HEALTH_OK between reboots.