no-squash: true cherry-picks commits in the wrong order

[earl-warren]

It applies the latest commit first intead of the last, which can lead to conflicts when two commits modify the same file.

To Reproduce
Steps to reproduce the behavior:

1. create a PR with two commits that modify the same line in a file
2. have git-backport try a backport with no-squash
3. see that it fails with a conflict

Expected behavior
It applies the commits in the right order instead and does not confict

Additional context

https://codeberg.org/forgejo/forgejo/actions/runs/10410#jobstep-5-31 is an example where that happened. Manually applying the same commits in the right order do not lead to conflicts.

[earl-warren]

I'll work on a fix now.

[lampajr]

Good catch, I can confirm that commits are applied in the wrong order (LIFO workflow) whereas the correct order should follow FIFO mechanism.