Refuse to release a version older than the last one

[menjoo]

0.0.9 after 0.1.1 currently releases cleanly: it is valid semver, is not a -SNAPSHOT, and
v0.0.9 does not exist, so all four checks in "Check the version" pass it. Publishing to Central
is the irreversible half, so that is worth closing.

The comparison

Two deliberate looseness choices, both to avoid half-implementing semver precedence in bash:

• Numeric core only — 1.0.0-rc1 is compared as 1.0.0.
• "Not older" rather than "strictly newer" — this is what lets 1.0.0 follow 1.0.0-rc1,
  which a strict-greater check would wrongly block. An exact repeat is already refused by the
  tag-exists check immediately above.

Residual gap: 1.0.0-rc2 after 1.0.0 is allowed. Rare and ambiguous enough not to be worth the
machinery.

Field-wise numeric sort (sort -t. -k1,1n -k2,2n -k3,3n) rather than sort -V, which is not
portable across GNU and BSD and orders pre-release versions wrongly regardless.

Tested

Tags	Version	Result
v0.1.0 v0.1.1	0.1.2, 0.2.0, 1.0.0	allow
v0.1.0 v0.1.1	0.0.9, 0.1.0	refuse
v0.1.0 v0.1.1	0.1.11, 10.0.0	allow — lexicographic comparison gets both backwards
v0.1.0 v0.1.1	0.1.1	allow — correctly deferred to the tag-exists check
… v1.0.0-rc1	1.0.0	allow — the case a strict-greater check breaks
none	anything	allow

Why the input stays

It guards a different failure mode, so the new check does not subsume it:

Guard	Catches
requested == committed	main isn't where you think — in either direction
monotonic vs latest tag	main went backwards

If you believe main is on 0.1.2 and someone merged 0.2.0, monotonicity passes and 0.2.0 ships.

It is also what run-name reads. run-name is evaluated before any job starts and can only use
the github, inputs and vars contexts, so it cannot read gradle.properties — dropping the
input would put the Actions list back to a column of identical "Release" entries, which is what #8
was merged to fix.

Ordering

Independent of #11 and #12; touches a different region of release.yml than #12 does.