getChanges ">=" and "<=" comparison prefixes behave like ">" and "<"

The getChanges macro accepts four comparison prefixes on its list-valued parameters: >, <, >= and <=. Only > and < work. A filter written with >= or <= silently returns the wrong set of changes — no error, just missing rows.

Steps to reproduce

On a page inside the space the application is installed in:

{{getChanges products="XWiki" versions=">=12.0" contextVariable="changeDocs"/}}

Expected: the changes of version 12.0 and later.
Actual: only the changes of versions strictly after 12.0 — every change of 12.0 itself is missing.

<= has the mirror problem: versions="<=12.0" excludes 12.0.

Cause

In application-releasenotes-ui/src/main/resources/ReleaseNotes/Code/Change/GetChangesMacro.xml, the #addClause Velocity macro tests the one-character prefixes before the two-character ones:

#if ($item.startsWith('>'))
  ... "${class}.${name} > :${name}${foreach.count}"
#elseif ($item.startsWith('>='))
  ... "${class}.${name} >= :${name}${foreach.count}"
#elseif ($item.startsWith('<'))
  ... "${class}.${name} < :${name}${foreach.count}"
#elseif ($item.startsWith('<='))
  ... "${class}.${name} <= :${name}${foreach.count}"

">=12.0".startsWith(">") is true, so the >= branch is unreachable and the clause is built with >. <= falls into the < branch for the same reason.

The companion #addBinding macro gets the order right — it tests >=/<= first and strips two characters — so the bound value is correct and only the operator is wrong. That is why the query runs and returns plausible but incomplete results rather than failing.

Suggested fix

Test the two-character prefixes first in #addClause, so its branch order matches #addBinding.