Drop containerd by moving to helm v3.21.3

[dimitri-nicolo]

Description

Removes containerd from the operator instead of bumping it again.

This is now a cherry-pick of master's own fix, 3fce8aca0 ("chore(deps): bump helm to v3.21.3 and oras-go to v2.6.2 to drop vulnerable containerd", #5100), rather than the equivalent change written from scratch. The resulting tree is byte-identical to the previous revision of this PR — only the commit's provenance and message changed, so it should be easier to review against what already shipped on master.

containerd isn't used here. It arrives via pkg/render/istio → helm's pkg/action → helm's OCI pkg/registry → containerd/remotes. That render code only uses helm as a local template renderer — it loads four embedded chart tarballs with DryRun/ClientOnly set and never contacts a registry — but pkg/action imports pkg/registry unconditionally, so 11 containerd packages get linked into the binary on a path nothing can reach.

helm v3.21.3 swapped containerd for oras-go/v2, so moving to it drops containerd entirely. pkg/render/istio/resources.go is byte-identical to master's — no code change needed.

What the pick had to carry

Master was already on client-go v0.36.2 and controller-runtime v0.24.1 when it made this change; this branch is on v0.35.7 / v0.23.3, and helm v3.21.3 requires client-go v0.36.2. So the conflict resolution brings the version floor with it:

	before	after
helm	v3.20.2	v3.21.3
controller-runtime	v0.23.3	v0.24.1
k8s.io/{api,client-go,apimachinery,apiserver,apiextensions-apiserver}	v0.35.7	v0.36.2
containerd	v1.7.34 + 3 more	gone

These can't be split into two buildable commits, which is why it stays one:

• Bumping k8s.io first fails — k8s.io/api v0.36 removed scheduling/v1alpha1, which helm v3.20.2's k8s.io/kubectl still imports.
• Bumping client-go without controller-runtime fails — v0.23.3 doesn't support client-go v0.36 (handlerRegistration is missing HasSyncedChecker).

v3.21.3 is also the first and only containerd-free helm release, so there's no smaller bump that gets there:

helm	go directive	containerd in go.mod
v3.20.0 – v3.21.0	1.25.0	yes
v3.21.1, v3.21.2	1.26.0	yes
v3.21.3	1.26.0	no

If that's too much for this branch, the alternative is to keep bumping containerd as advisories land — it's unreachable code, so exposure is limited either way.

oras-go stays at this branch's v2.6.2, already ahead of what helm v3.21.3 asks for, keeping the CVE-2026-50151 / CVE-2026-50163 pin note.

Verified

• Builds; containerd goes from 11 linked packages to 0 and leaves go.mod entirely.
• pkg/render/istio (the only helm consumer) passes.
• pkg/render unchanged at 527/530 — the same 3 failures occur on a clean tree; pkg/render/gatewayapi likewise has the same 1 pre-existing failure. Both diffed against the branch without this change.
• No generated files change (controller-gen is pinned by the build image, not go.mod).

Companion PRs

• release-v1.42: same pick, much smaller — that branch is already on controller-runtime v0.24.1 / client-go v0.36.3, so only helm and oras-go move.
• release-v1.41: not possible. It's on Go 1.25.7 with no GOTOOLCHAIN override, and every helm ≥ v3.21.1 requires Go 1.26 (helm.sh/helm/v3@v3.21.3 requires go >= 1.26.0). Dropping containerd there would mean bumping the branch's Go toolchain first.

Release Note

None