minecraft-server: restore the java21 line (4.0.1+up2026.8.2.java21)

Closes the three-step round that carried the #99 null-safety to every Java
line. Pure restoration of the directory to the newest line:

  version:            4.0.0+up2026.8.2.java17 -> 4.0.1+up2026.8.2.java21
  appVersion:         "2026.8.2-java17"       -> "2026.8.2-java21"
  minecraft.version:  "1.20.1"                -> "1.21.1"

Nothing changes in content, and that is not a claim but a measurement. Against
the java21 state published from #156, the ENTIRE chart tree differs in exactly
one line - the chart version - and .Chart.Version is not read by any template,
so the rendering is byte-identical:

  4.0.0+up2026.8.2.java21 (published) -> this chart:
    file tree: 1 differing line, Chart.yaml version
    rendering: byte-identical (CI values, serverpack init container enabled)

  main (java17) -> this chart:
    exactly TWO differences, both the line selection itself -
    image itzg/minecraft-server:2026.8.2-java17 -> :2026.8.2-java21 and
    env VERSION 1.20.1 -> 1.21.1.

Why 4.0.1 and not 4.0.0: 4.0.0+up2026.8.2.java21 is already in the registry
from #156, and helm push overwrites an existing OCI tag without complaint. The
version check in validate-charts.yml does not catch this - it compares only
against github.base_ref, where the version would read java17, so a republished
4.0.0 would pass the gate and silently overwrite the published artifact. Tracked
as #160.

What this round achieves, measured across the three published line states:
templates/ and values.schema.json are byte-identical on java8 (f7047b8), java17
(2b22ce5) and java21 (this chart); values.yaml differs only in minecraft.version
and the comment naming the appVersion; and all three now carry initImage
alpine:3.24, so the bump that had reached only java21 is no longer missing on
the other two. All three lines therefore run the same hardening, the same three
exec probes, the same resources handling and the same null-safe fallbacks.

Left untouched on purpose: the float64 quantity finding (#157) and seccompProfile
(#161) - the latter has to be pulled through all three lines and has its own
unknowns in gosu and the serverpack init container.

Refs #99

minecraft-server/Chart.yaml

@@ -13,8 +13,8 @@ type: application
 # continuously, so a pod restart could pull a different image than the last one
 # without anything being recorded anywhere. The dated tags are immutable, so the
 # image is now pinned by the chart version like every other chart in this repo.
-version: 4.0.0+up2026.8.2.java17
-appVersion: "2026.8.2-java17"
+version: 4.0.1+up2026.8.2.java21
+appVersion: "2026.8.2-java21"
 
 maintainers:
   - name: jklein

minecraft-server/values.yaml

@@ -226,8 +226,8 @@ minecraft:
   # This value must match the Java line of the chart version: the image tag
   # comes from .Chart.AppVersion, so the JVM is fixed per published chart
   # version. Java 8 runs Minecraft up to 1.16.5, 1.18-1.20.4 need Java 17 and
-  # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java17".
-  version: "1.20.1"
+  # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java21".
+  version: "1.21.1"
 
 # curseforge, ftb and curseforgeServerpack are mutually exclusive - enabling
 # more than one is rejected by the chart (before 1.0.0 it silently rendered a