gitlint: Add rebase hint for older non-compliant commits

[ThePo1es]

Bugfix

Description

The check-commit-messages job prints a hint that only suggests git commit --amend. That command rewrites the most recent commit, so it does not help when an older commit on the branch is the one violating the rules - which is exactly the case reported in #3057, where two commits were flagged and the offending one was not at HEAD.

This adds an interactive rebase hint next to the existing amend hint, so both cases are covered.

The rebase hint points at origin/<base-branch>, the same revision the check compares against (gitlint --commits origin/<base-branch>..HEAD). That way the range offered for rewriting is exactly the range that was verified, and contributors do not have to work out a commit hash or an off-by-one ~1 themselves.

Example output when the check fails:

WARNING: Your commit message does not follow the required format.
Formatting rules: https://eclipse-score.github.io/score/main/contribute/general/git.html

If only the most recent commit is affected, run:

 git commit --amend

If an older commit is affected, start an interactive rebase and
change 'pick' to 'reword' for every commit reported above:

 git rebase -i origin/main

After updating the commit messages, force-push:

 git push --force-with-lease

Note: the issue suggests git rebase -i <commit-hash>. Since git rebase -i <commit> starts after the named commit, that form would not make the reported commit editable; origin/<base-branch> avoids the pitfall and needs no hash lookup.

Verified locally: the action YAML parses, the extracted script passes sh -n, and the failure branch produces the output shown above.

Related ticket

closes #3057 (bugfix ticket)

[MaximilianSoerenPollak]

I think it might be worth having a conversation if gitlint should be enforced in this repo or not.

[ThePo1es]

Agreed that the bigger question deserves its own discussion, and that call is yours to make - I have no stake in the outcome either way.

This PR is orthogonal to it: it does not argue for keeping the check, only makes the message correct for as long as the check exists. Today a contributor whose older commit is flagged is told to run git commit --amend, which cannot reach that commit - so the current hint is actively misleading rather than merely incomplete.

If the outcome is to drop gitlint here, this becomes moot and I will close it. Happy to move it back to Draft in the meantime if you would rather settle the larger question first.

[MaximilianSoerenPollak]

The change makes sense to me, if we want to keep gitlint here anyway is a different discussion