Update minecraft-server to the java21 line (0.4.0+upjava21)

Last of the three Java-line publishes; main comes to rest on java21, the line
of the only running server, and the registry holds all three tags.

Only the two version lines in Chart.yaml change. Because the source chart in
cluster-config is itself on java21, this final state renders byte-identical to
it for mc-ftb-skies-2 with its real values file - the published end state is
exactly what cluster-config runs today.

The CI install values move along with the appVersion, as in the java17 PR:
the JVM is fixed per published chart version and no single Minecraft version
boots on all three lines. Since the chart has no probes, a version the JVM
cannot load would crash after the rollout returned and still leave a green
install-test behind. minecraft.version therefore moves 1.20.1 -> 1.21.1, which
is also what ftb-skies-2 sets in its real values file, so CI exercises the
production version. ci/ is outside the chart directory and is neither packaged
nor published.

minecraft-server/Chart.yaml

@@ -15,10 +15,10 @@ type: application
 # This is the chart version. This version number should be incremented each time you make changes
 # to the chart and its templates, including the app version.
 # Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 0.4.0+upjava17
+version: 0.4.0+upjava21
 
 # This is the version number of the application being deployed. This version number should be
 # incremented each time you make changes to the application. Versions are not expected to
 # follow Semantic Versioning. They should reflect the version the application is using.
 # It is recommended to use it with quotes.
-appVersion: "java17"
+appVersion: "java21"