Compare versions numerically so the head detector runs on 26.x

[Aelshi-nui]

This is the narrow one, off current master, just the two files.

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. That means 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 without 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 version gate becomes isAtLeast(FIRST_AFFECTED_VERSION), and FIXED_IN_VERSION goes through the same comparison, so setting it will now work rather than silently doing nothing.

Nothing else changed. detect() is untouched, so the #179 profile work is exactly as you left it, and there are no dependency or plugin.yml changes. New branch rather than my fork's master, so no file mode churn in the diff.

On verification: the version comparison has 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 that getBukkitVersionType relies on, and empty input. All pass.

One thing to flag, unrelated to this PR. Master does not currently build for me: net.milkbowl.vault:VaultUnlockedAPI:2.19.0 cannot be resolved. codemc publishes that artifact only up to 2.15, jitpack has 2.3 and 2.10-test-6, and Maven Central has none, so I could not find 2.19.0 anywhere. An unmodified checkout of master fails the same way, so it is not from this change, but it does mean I compiled the two changed files directly against spigot-api rather than running a full mvn package. If 2.19.0 lives somewhere that is not in the pom's repository list, adding that repo would fix it for anyone building fresh.

[Aelshi-nui]

Superseding this with #181. Same two files, plus the one line that makes master build: VaultUnlockedAPI 2.19.0 is not published, but 2.19 is, in the codemc-creatorfromhell repo that is already in the pom. My note above about it being unfindable was wrong, and the new PR explains it properly.