fix: use --unreleased --bump (not --latest --bump) so version actually bumps

[fiunchinho]

Summary

Apologies — second swing at the same regression. PR #15's "fix" silently broke the bump computation. After #15 merged, the workflow ran successfully but said `No releasable commits since v1.4.2` and skipped tagging. We never got the v1.4.3 release that should have validated #15 itself.

What went wrong (again)

--latest --bump looked like the right composition to me — "latest release + bump". It isn't. With both flags, git-cliff returns the latest existing tag and silently ignores the bump. So outputs.version was always the current tag and the decide step always said "skip".

Verified locally:

$ git-cliff --bump --context | jq '.[0].version'     # full JSON, first element
"v1.4.3"
$ git-cliff --bump --latest --context | jq '.[0].version'   # the broken combo from #15
"v1.4.2"                                              # ← returns existing tag, not bump
$ git-cliff --unreleased --bump --context | jq '.[0].version'   # the right combo
"v1.4.3"                                              # ← bumps correctly, single release

Fix

One word again. Replace --latest with --unreleased:

- git-cliff --bump --latest --context > cliff-context.json
+ git-cliff --unreleased --bump --context > cliff-context.json

--unreleased filters to commits not yet in any tag → --bump computes the version from those → --context outputs as JSON. Returns a single-release JSON containing just the bumped version. Render is then trivially correct.

Updated the explanatory comment in the YAML to call out the trap so the next person to look at this doesn't make the same mistake. Both --latest and --unreleased look like single-release filters; only one composes with --bump.

Lesson learned

I missed this in local testing because my reproduction setup wasn't representative of the production state. A fresh clone with the actual remote tag history (which I finally did when debugging this) reveals the issue immediately. Going forward, validation needs to happen on a fresh clone at the same commit the workflow would run from.

Test plan

• Local on fresh clone at PR fix: render only the latest release's notes, not the full history #15's merge commit: --unreleased --bump --context returns v1.4.3 with one release in JSON; render produces clean single-release notes.
• After squash-merge:
  • Workflow run produces v1.4.3 (this PR is fix: → patch bump from v1.4.2)
  • Release notes body contains ONLY this PR's bullet + the v1.4.2 → v1.4.3 Full Changelog footer
  • No older releases in the body

Cleanup follow-up

v1.4.1 and v1.4.2 still have bloated bodies (from PR #13's original regression). Those will stay until manually corrected via gh release edit — fixing the workflow doesn't retroactively rewrite history. Happy to do that cleanup after this lands and we confirm v1.4.3 is clean.