ci: automate changelog from PR names

[shamykyzer]

• Add Changelog CI workflow for release PRs
• Reformat generated changelog to match existing style (version date, bullet format)
• Add changelog-ci config and reformat script
• Update CONTRIBUTING: changelog auto-generated, document release workflow

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.70%. Comparing base (6be3e08) to head (0fd3784).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #352   +/-   ##
=======================================
  Coverage   99.70%   99.70%           
=======================================
  Files           9        9           
  Lines        1348     1348           
=======================================
  Hits         1344     1344           
  Misses          4        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[shamykyzer]

Hello @rpreen , i looked into it and Commitizen didn’t feel like the right fit here because it’s commit based and mainly release time focused.

Since we want PR title based entries, i went with Changelog CI plus a small reformatter as it matched the repo policy and will keep the versioning and the release process unchanged.

Also I couldn't continue this development further due to the bot not having write permissions I think.

Let me know what you think and where I can go from here. 👍🏼

[rpreen]

I think this is a more complicated solution than we need. If I understand correctly, any time someone opens a PR the bot will push a new commit onto their branch, which they will probably not expect or appreciate. Their local branch will then be behind, so they will have to do a pull before they can make any further commits. If multiple PRs are opened simultaneously both will modify the changelog in the same location causing a merge conflict.

I think for us we need a simpler solution that only runs before a release - I just added a comment on #327 about this.

[shamykyzer]

• Implemented the updated script/tool that inserts new git-cliff entries under the most recent "Version" section in CHANGELOG.md (this avoids constant creation of new versions like before)
• Updated CONTRIBUTING.md with clear guidance on branch/history behavior, PR-link generation rules, quick verification commands, and a safe rollback step.
• Also added fail-safe logic to avoid any duplicate entries

@rpreen could you try running the script and tell me what you think? I am more than glad to add more commands such as for updating the version or implementing it in github actions .yml only when push if you change your mind!

[rpreen]

I have:

1. fixed the existing changelog by removing the post v0.4.12 entries which have been incorrectly added there in other PRs recently;
2. removed your script - we should keep this simple and adding extra scripts is unnecessary here - although we may eventually want to add a ci workflow to do it automatically when we've had a little time to test this and everyone is consistently merging PRs with conventional commit messages;
3. simplified the instructions in the contributing guide - given this is a Python project it is much easier to use pip or uv to install git-cliff - why would I bother installing all the rust/cargo stuff and building from source?
4. made some tweaks to the changelog output format

this now needs checking and potentially tweaking the contributing guide and cliff.toml - i just did this quickly and i'm tired