Compare versions numerically so the head detector runs on 26.x, and fix the VaultUnlockedAPI version

[Aelshi-nui]

This replaces #180. Same two files as before, plus the one line that makes master build. Two commits, so the build fix can be dropped if you would rather take it separately.

The version detection fix, unchanged from #180:

isRelevantForCurrentVersion() decided whether the detector applied by matching on the version string, with checks like version.contains("1.21.1"). Minecraft dropped the leading "1." in 2026, so the drops after 1.21.11 are 26.1, 26.1.1, 26.1.2 and 26.2, and none of those match any of those checks. IncompatibilityChecker does "if (!detector.isRelevantForCurrentVersion()) continue;" before it ever calls detect(), so on a 26.x server the detector reports itself irrelevant and gets skipped entirely. The empty player head NPE is unguarded again on exactly the versions that still have the bug, and the offline skull owner fix from #179 never runs there either.

versionUtil now parses a version into its numeric parts and exposes isAtLeast(String). Both numbering schemes compare correctly against each other with no special cases, because 26 is greater than 1. getBukkitVersionType() keeps its old behaviour, it just runs on the numeric comparison instead of the padded string compare, which was only accidentally right. The detector's gate becomes isAtLeast(FIRST_AFFECTED_VERSION), and FIXED_IN_VERSION now goes through the same comparison, so setting it will actually work rather than silently doing nothing. detect() is untouched, so your #179 profile work is exactly as you left it.

The build fix, which is new:

In #180 I said VaultUnlockedAPI 2.19.0 could not be found anywhere, and that was wrong. It is in the codemc-creatorfromhell repo, which is already in the pom. That repo publishes 2.15, 2.16, 2.17, 2.18, 2.19 and 2.20. There is no 2.19.0, so resolution fails on the version string rather than the repository. Changing it to 2.19 fixes it, and I verified 2.19 and 2.20 both return 200 for jar and pom while 2.19.0 returns 404 on every repository in the pom.

With that corrected, resolution succeeds and the build gets to compiling 176 sources. What remains is unrelated to this PR and I could not verify it here: BlockLockerHook, LWCHook, ResidenceHook, EssentialsHelper, CMIWorthHandler and EssentialsWorthHandler fail because blocklocker 1.7, LWCX 2.2.5, residence 4.8.8.2, CMI-API 9.7.14.3 and essentials 2.22.0 are not published in any of the ten repositories the pom lists. I checked each one directly. Those build for you because the jars are in your local repository, the same way you suggested I install LWCX, so a clean checkout will stop there for anyone else. Not something I want to touch in this PR, but worth knowing.

On verification: both changed files compile cleanly, and with the version string corrected every remaining error line is inside those six files, none in versionUtil or the detector. The version comparison carries twenty assertions covering the ordering across the scheme change, including 1.21.11 below 26.1, 26.1 below 26.1.1 below 26.1.2 below 26.2, real Bukkit strings like "26.2-R0.1-SNAPSHOT", the 1.4.5 and R0.3 pairs getBukkitVersionType relies on, and empty input. All pass.

Branched off current master, so no file mode churn and no dependency changes beyond that one version string.