chore: pin GitPython for release bump

[leongdl]

What was the problem/requirement? (What/Why)

The Release: Bump workflow is broken. Run 32913960024
(dispatched with force_version_bump: minor right after #358 merged) died in the
bump step:

INFO     Using group 'release' options, as '(mainline|release|patch_.*)' matches 'mainline'
##[error] type object 'Actor' has no attribute 'name_email_regex'

It fails immediately after config load, before any git or version work.

GitPython 3.1.60 dropped Actor.name_email_regex, which python-semantic-release
10.6.1 still references. requirements-release.txt pins PSR (== 10.6.*) but not
GitPython, and PSR depends on gitpython~=3.0 — so the CI job's fresh
pip install -r requirements-release.txt resolved gitpython-3.1.60 and broke.
Nothing in this repo changed; the transitive dependency floated underneath it.

This blocks the 0.12.0 release, which matters more than usual right now: the
BREAKING CHANGE: footer from #358 is on mainline, and until the bump runs, the
extra_let_bindings removal from #357 is sitting unreleased.

What was the solution? (How)

Pin GitPython == 3.1.59 in requirements-release.txt, matching the fix
openjd-model already landed in
12816ad.
Same pin, same reason, so the two repos stay consistent.

I added a comment recording why the pin exists and when it can go away — a bare
pin on a transitive dependency is the kind of line that gets "cleaned up" a year
later and silently reintroduces this failure.

What is the impact of this change?

The release bump works again and computes 0.12.0.

Release tooling only. No effect on the published package: requirements-release.txt
is not part of dependencies in pyproject.toml, so consumers are unaffected.

How was this change tested?

A/B against the workflow's own command, in a clean venv at this commit, on a
branch name matching branches.release:

semantic-release -v --strict version --no-commit --no-push --no-tag --minor

GitPython	Result
3.1.59 (this PR)	exit 0
3.1.60 (what CI resolved)	::ERROR:: type object 'Actor' has no attribute 'name_email_regex' — reproduced verbatim

So the pin is confirmed to be both the cause and the fix, rather than assumed.
With the pin in place the computed next version is 0.12.0 both with and without
the forced minor.

• Have you run the unit tests? Not applicable to this change — it touches only
  the release requirements file, which no test imports. The unit suite was run on
  chore: raise the openjd-model floor to 0.11.6 #358 at the immediately preceding commit.

Was this change documented?

• Are relevant docstrings in the code base updated? N/A. The pin carries an
  inline comment explaining the incompatibility and the removal condition
  (unpin once PSR ships a release compatible with GitPython 3.1.60+).

Is this a breaking change?

No. Release tooling only; no public contract is touched.

Does this change impact security?

No. It pins a build-time dependency to a slightly older patch release; no files,
directories, or permissions are affected.

Cross-port to openjd-rs

• This change does not affect runtime behavior (docs / tests / tooling only)

CI dependency pin for this repo's Python release tooling. No openjd-rs analogue.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-actions]

This pin is likely to be silently reverted by the repository automation, reintroducing the exact breakage it guards against.

.github/dependabot.yml runs the pip ecosystem on directory /, which covers this file — it has bumped python-semantic-release here many times already. Once GitPython == 3.1.59 is a tracked requirement, Dependabot will propose 3.1.60, which is a patch bump and therefore matches the pip-minor-patch group. .github/workflows/auto_approve.yml then auto-approves any dependabot[bot] PR, so the unpin can land on an approval nobody actually read, and the next Release: Bump run dies again with Actor has no attribute name_email_regex.

The explanatory comment above the pin is genuinely useful for humans, but Dependabot does not read it. Consider pairing the pin with an ignore rule so the constraint is machine-enforced — under the pip entry in .github/dependabot.yml:

    ignore:
      - dependency-name: "gitpython"
        versions: [">=3.1.60"]

That also keeps the two places in sync: whoever removes the ignore rule has to look at the pin, and vice versa.