Document release branch workflow in CONTRIBUTING.md

[pelesh]

Description

CONTRIBUTING.md documents feature branches but not how release branches are created and merged. This is a documentation-only change.

Closes #598

Proposed changes

Adds two sections to CONTRIBUTING.md after "Deleting your feature branch", based on the git branching model at https://nvie.com/posts/a-successful-git-branching-model/:

• Creating a release branch: branch release-<version> from develop, update version and CHANGELOG, allow only bug fixes and release preparation.
• Merging a release branch: merge into main (tag the merge commit) and back into develop, always with a merge commit (no squash or rebase) so both branches share the release commits as common ancestors. Subsections cover merging into main, merging into develop, and handling release-only fixes.

One deviation from the nvie model: release branches are kept after merging and reused for patch releases instead of creating hotfix branches.

Checklist

• All tests pass. (documentation only)
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra. (documentation only)
• The new code follows GridKit™ style guidelines. (documentation only)
• There are unit tests for the new code. (not applicable)
• The new code is documented.
• The feature branch is rebased with respect to the target branch.
• N/A The CHANGELOG.md has been updated to reflect the changes. Minor documentation change; CHANGELOG not updated.

Further comments

The no-squash rule is deliberate: squashing a release branch into main gives main and develop no shared ancestry for the release, causing spurious conflicts on later merges.

🤖 Generated with Claude Code

[nkoukpaizan]

Looks good! A couple of minor suggestions.