chore(release): bump chart to 0.6.2

[lucasmundim]

What

Bump the chart version + appVersion 0.5.1 → 0.6.2 to cut the first controller release on the reconnected pipeline (#76).

Why this version

Chart.yaml on main was stale at 0.5.1 while the latest published chart/image is 0.6.1 (the old flow derived the version from the git tag and never bumped the file). 0.6.2 is the next patch and makes Chart.yaml truthful again. The only functional change since v0.6.1 is the release-surface work in #76 (workflows + docs).

Release steps (parity gate is now live)

1. Merge this PR (Chart.yaml = 0.6.2 on main).
2. Tag v0.6.2 on the merged commit and push.

On the tag, docker-publish.yml:

• builds + pushes images 0.6.2 (multi-arch),
• publish-chart asserts Chart.yaml == 0.6.2 (passes), packages + pushes chart 0.6.2 to GHCR,
• creates the GitHub Release v0.6.2 with the chart .tgz — the first Release of the new flow (the Releases page has been frozen at the chart-releaser 0.5.1 fossil).

Note: one-time restart on merge

appVersion feeds the app.kubernetes.io/version pod-template label, so merging this rolls the controller once per env on the next ArgoCD sync. The image is SHA-pinned, so it's a no-op restart (same code) — expected at release time.

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[leandrobmarinho]

Trivial, correct release bump: Chart.yaml version and appVersion both move 0.5.1 -> 0.6.2 (one file). Verified both fields are bumped together so the pre-merge version==appVersion parity check passes (CI green), and they'll match the upcoming v0.6.2 tag so the authoritative 'Assert Chart.yaml matches the release tag' gate in docker-publish.yml passes too. The 0.5.1->0.6.2 jump (skipping 0.6.0/0.6.1) is intentional and correct - the chart file lagged at the last chart-releaser release while v0.6.0/v0.6.1 were already tagged, so bumping straight to 0.6.2 realigns the chart with the upcoming tag (image tag:'' defaults to appVersion, so it deploys :0.6.2 consistently). No code/RBAC/manifest/workflow changes, all checks green. Looks good.

[shingonoide]

The bump itself is correct: 0.6.2 is the next unused patch (no v0.6.2 tag or release exists yet), version and appVersion move together, and the parity gate passes. Two things I verified that are worth recording:

• The parity-gate-vs-publish gap I raised on #76 is now closed. publish-chart in docker-publish.yml runs the "Assert Chart.yaml matches the release tag" step (lines 177-188, exit 1 on mismatch) before helm package / helm push, and the job is tag-gated, so a mismatched Chart.yaml now fails before anything ships rather than only flagging a separate check. Good fix.
• Merging this is safe on its own: docker-publish.yml has paths-ignore: ["deployment/**"] on push/PR and publish is tag-gated, so no chart or release is produced until v0.6.2 is pushed. The appVersion bump rolls the pods once per env but is a true no-op restart, since all four overrides/*.yaml pin the image to a SHA digest that wins over .Chart.AppVersion.

One should-fix before (or with) the release:

Stale install version in the docs. The root README.md still pins --version 0.6.1 in the three install/upgrade examples (lines 105, 115, 126), and deployment/openfilter-pipelines-controller/README.md:28 uses 0.6.1 as the example version. A user copy-pasting the root README commands right after the 0.6.2 release installs the previous chart. Bumping those to 0.6.2 in this PR keeps the docs truthful with Chart.yaml.

Nothing else in the chart needs to move (values.yaml image.tag is empty by design, Chart.lock pins the valkey subchart independently).