A filter value whose comparison operator is preceded by a space is read as a pattern

Reproduced and fixed on a real wiki.

The same custom report, the same URL, the same data – only the application-releasenotes-api jar differs:

/xwiki/bin/view/ReleaseNotes/Code/Report?action=report&products=VersionProduct&versions=9.0, >=10.0

The product has one change stored against 9.0 ("A nine change") and one against 10.0 ("A ten change").

• Before () – only "A nine change". The value " >=10.0" was read as a like pattern of the text ">=10.0", which matches no version, so the second half of the filter silently contributed nothing.
• After () – both changes, which is what the same filter written "9.0,>=10.0" has always returned.

The control confirms nothing else moved: the space-free spelling "9.0,>=10.0" renders exactly the same page before and after the fix.

The fix trims each value of a filter before looking for the operator it is prefixed with, instead of only after. DefaultChangeQueryParserTest gains a parameterized case per spelling (" >=9.0", ">= 9.0", " >= 9.0", " = 10.0", " 9.0"), and asserts the operator on its own because a pattern of a comparison and the comparison itself are written the same way, so a failure comparing whole filters is unreadable.

Full build green with -Pquality: 130 -api + 37 -rest + 121 -ui tests, 0 Checkstyle violations. GetChangesMacroPageTest, the frozen-contract oracle, is unchanged at 35/35.