fix(helm-chart): port the helm version pin to support/1.x so builds stop resolving it via the GitHub API

[jfallows]

Symptom

Builds on support/1.x fail intermittently in cloud/helm-chart with a GitHub API 403:

[ERROR] Failed to execute goal io.kokuwa.maven:helm-maven-plugin:6.17.0:init (default-init)
        on project helm-chart: Failed to get helm version from github api, response code was 403 -> [Help 1]

Observed on run 30940079197 (PR #2305). Every module up to and including docker-image succeeded, helm-chart failed after 0.544s, command-log was skipped. No test failures — nothing in the log matches Tests run: … Failures: [1-9], <<< FAILURE, or <<< ERROR.

Root cause

helm-maven-plugin's init goal downloads the Helm binary. When helmVersion is not configured it must first resolve "latest release" through api.github.com/repos/helm/helm/releases/…. That call is unauthenticated and comes from a shared Azure runner IP against the 60-request/hour anonymous limit, so it 403s whenever the limit happens to be exhausted. It is a version-discovery call — not a chart or dependency fetch — so the failure is pure avoidable network dependency.

The two branches differ by exactly one line. The plugin blocks in cloud/helm-chart/pom.xml are otherwise identical, same plugin version 6.17.0:

	develop	support/1.x
<helmVersion>	${helm.version} (cloud/helm-chart/pom.xml:60)	absent
helm.version property	3.16.4 (pom.xml:66)	absent

So develop fetches the pinned binary directly and never calls the API, while support/1.x rolls this dice on every build. The pin reached develop via the 2.0.0-alpha-21 merge (c73b19aca) and was never carried back to the 1.x line, which means this is not a one-off and will keep recurring on support/1.x at random.

Fix

Port the pin to support/1.x:

• add a helm.version property to the root pom.xml (3.16.4 matches develop; a newer 3.x is fine if preferred)
• add <helmVersion>${helm.version}</helmVersion> to the helm-maven-plugin configuration in cloud/helm-chart/pom.xml

Keep the same conventional-commit subject as the change on develop so the merge-report tooling can match it by subject.

Worth considering at the same time

In the default develop profile — the one active for every PR and CI build, since it activates on release != true — both branches already set helm.push.skip and helm.package.skip to true (support/1.x pom.xml:646-647, develop pom.xml:669-670). So a PR build performs Helm version discovery and downloads the Helm binary for a chart it then neither packages nor pushes.

Skipping init in that profile as well would remove the download from every PR build on both branches, not just the API call from one. That is a broader change than the port and affects develop too, so it may be better as its own issue; the plugin exposes a per-goal skip for init, whose exact property name should be confirmed against the 6.17.0 docs before relying on it.

A third option, useLocalHelmBinary + autoDetectLocalHelmBinary, would use the Helm binary already present on GitHub runners instead of downloading one. Neither branch sets these today.

Acceptance criteria

• support/1.x pins the Helm version; cloud/helm-chart no longer calls the GitHub API during init
• A support/1.x build packages the chart correctly with the pinned version (verify under -Drelease too, where helm.package.skip is not set)
• The commit subject matches the develop-side change so subject normalization can pair them

Not in scope

The intermittent mcp.proxy example failure (#2313) and the release-workflow changes (#2303, #2305) — unrelated, and this failure is not caused by either.