perf: consolidate git-cliff invocations behind a single install

[fiunchinho]

Summary

Replaces two orhun/git-cliff-action invocations with one install + one shell step. Saves ~5–8s per workflow run and removes a workaround for the action's flaky version output.

What changes

- - uses: orhun/git-cliff-action@SHA       # install + --bumped-version
- - uses: orhun/git-cliff-action@SHA       # install + --latest --strip all
+ - uses: giantswarm/install-binary-action@SHA   # install git-cliff once
+ - shell step:
+     git-cliff --bump --context > cliff-context.json   # ONE expensive call
+     jq -r '.[0].version' cliff-context.json           # extract version
+     git-cliff --from-context ... --output ...         # cheap render (no API)

Why this is correct

git-cliff --bump --context does all the expensive work — walks commits, queries the GitHub API per commit for PR lookups, emits a JSON context with everything baked in. --from-context then renders the configured template against that JSON with no further API calls and no git traversal. Local timing: 38ms.

Output is identical to the previous two-action flow because:

• --bump uses the same bumped-version semantics as the old --bumped-version
• The cached context already reflects what --latest would have seen after the tag push (both render the bumped release's commits)

Side benefits

1. Removes the outputs.content trim hack. The previous flow read steps.cliff.outputs.content (the action's stdout capture) and trimmed whitespace, because the action's outputs.version was unreliable for --bumped-version (it parsed the wrong JSON field). Now we read the version straight from our own cliff-context.json via jq — no quirky action behavior to work around.
2. Single source of truth. The same JSON drives both the bump decision and the rendered notes. Eliminates any risk of them diverging if cliff config or git state changes between the two action invocations.
3. One less external action to trust/pin. install-binary-action is already in use elsewhere in the giantswarm fleet (e.g., for gitsemver).

Test plan

• Verified locally: git-cliff --bump --context | jq '.[0].version' returns the correct bumped version; git-cliff --from-context ... --strip all renders the same body the old flow produced.
• After squash-merge:
  • Workflow run completes faster (compare against the ~15s baseline of v1.4.0)
  • v1.5.0 (or whatever the bump produces, this is a perf: so no bump on its own — but the squash commit would be perf: ... (#13) which IS conventional and would bump per cliff.toml... wait, perf maps to Changed group but doesn't trigger a bump in git-cliff's default. So this PR might produce NO release. Worth noting.)

Heads-up about the bump: this is perf: which git-cliff's default bumper treats like docs/chore — no bump triggered. The merge of this PR may not produce a release. If you want to validate end-to-end, the next conventional fix: or feat: after this lands will validate everything.