fix(tag list): change sorting to avoid bug

[sanderob]

Summary of changes

When there are several tags on one commit, the tags with common commit arrive in the opposite order when using sort=-committerdate. When using sort=committerdate, the latest tag is at the bottom of the list, but the tags arrive in the correct order, even when there are several tags on one commit.

This pull request solves #345.

For instance, with the following git log:

commit abc123 (tag: v0.0.3, tag: v0.0.2, master)
Author: github-author
Date:   Wed Jul 23 16:24:51 2025 +0200

    Commit message 2

commit xyz789 (tag: v0.0.1)
Author: github-author
Date:   Wed Jul 23 16:05:26 2025 +0200

    Commit message 1

The command git tag --list --sort=-committerdate will yield:

v0.0.2
v0.0.3
v0.0.1

And the action will try to bump from v0.0.2. However, the command git tag --list --sort=committerdate will yield:

v0.0.1
v0.0.2
v0.0.3

Which will, in combination with tail -n 1 instead of head -n 1, make the action bump from v0.0.3

Breaking Changes

Do any of the included changes break current behavior or configuration?

NO

How changes have been tested

Yes

List any unknowns

None known.

[postalservice14]

Thanks for tackling this @sanderob — the multi-tag-on-one-commit case is a real bug.

One concern: when several tags share a commit they also share a committerdate, so this still
relies on git's secondary sort key, which is lexical refname, not semver. That orders the
example (0.0.1/0.0.2/0.0.3) correctly, but it would mis-rank double-digit versions — e.g.
0.0.9 vs 0.0.10, where lexical sort puts 0.0.9 last and the action would pick the wrong
"latest" tag.

The repo context already sidesteps this with --sort=-v:refname (true version sort). Could we
make branch version-aware too? git accepts multiple --sort keys (last key = primary), so
something like --sort=committerdate --sort=v:refname keeps the commit-date intent but breaks
ties by semver instead of ASCII.

Either way, since the maintainers have asked for test coverage before merging behavior changes
(#184), a bats case with two+ tags on one commit including a double-digit patch would lock this
in and prevent regressions. Happy to help add one.