ci: drop push-tags trigger from release-helm-chart.yaml to fix race with release-published

[saadqbal]

Problem

.github/workflows/release-helm-chart.yaml listens to BOTH:

• push: tags: ['client-v*', 'v*']
• release: types: [published]

The established release path is gh release create v<x.y.z>, which fires both events simultaneously. Two workflow runs race to package the chart and push the same commit to gh-pages. The slower run consistently fails with:

! [remote rejected] gh-pages -> gh-pages (cannot lock ref ... non-fast-forward)

Recent example — v1.3.2 cut today (2026-05-07)

• Run 25492826350 — event: push — succeeded
• Run 25492826437 — event: release — failed (gh-pages push rejected)

Artifacts (client-1.3.2.tgz, updated index.yaml, release asset) all landed correctly because the winning run did its job, but the failed sibling shows up as a red X on the release and is misleading noise for anyone debugging future releases.

Fix

Drop the push.tags trigger. Keep only release.types: [published].

gh release create is the established release path (per gh release list history — v1.0.0 through v1.3.2 all created this way). Dropping the tag-push trigger removes the race without changing the release UX.

The Upload chart to GitHub Release (on tag) step's if: startsWith(github.ref, 'refs/tags/') guard still evaluates true for release events (github.ref on a release event is the tag ref), so behavior of that step is preserved.

Acceptance criteria

• Next gh release create produces exactly one workflow run, with event: release.
• No failed sibling run.
• client-<version>.tgz, updated index.yaml, and release asset still land as before.

References

• Workflow file: .github/workflows/release-helm-chart.yaml
• Repo CLAUDE.md (default branch is develop; PRs assigned to saadqbal)