minecraft-server: publish the java17 line (4.0.0+up2026.8.2.java17)

Third of three line publications that carry the #99 null-safety to every Java
line. Templates and schema are the same for all three lines; only the
line-selecting fields change:

  version:            4.0.0+up2026.8.2.java8 -> 4.0.0+up2026.8.2.java17
  appVersion:         "2026.8.2-java8"       -> "2026.8.2-java17"
  minecraft.version:  "1.12.2"               -> "1.20.1"   (Java 17 runs
                                                            Minecraft 1.18-1.20.4)

What the diff does NOT show, same as for java8: the java17 line was last
published as 3.0.0+up2026.8.2.java17, and since then main also moved the
serverpack init image from alpine:3.22 to alpine:3.24 (commit 5a35ea4, which
landed on the java21 line only). That bump rides along here.

It is invisible in the diff against main, because relative to main the file
already says 3.24 - the java8 publication in #159 brought it there. Relative to
what a java17 release actually runs today it is a base-image change, so it is
named here rather than left to be discovered.

Measured against ci/minecraft-server/test-values.yaml with the serverpack init
container enabled, compared structurally (documents paired by kind/name,
recursive over keys) instead of line by line:

  3.0.0+up2026.8.2.java17 (published) -> this chart:
    exactly ONE difference, initContainers[0].image alpine:3.22 -> alpine:3.24.

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

Hardening, the three exec probes, resources and the init.sh chown are unchanged,
which is what the null-safety was built to do: it changes what an ERASED block
renders, not what the defaults render.

At file level the line invariant holds exactly - against main's tree the only
differing files are Chart.yaml and values.yaml, in the three line fields plus
the comment naming the appVersion. _helpers.tpl, values.schema.json and both
templates are byte-identical across the lines.

The null-safety itself is not re-swept - #156 proved it on identical templates.
Confirmed once on this build that it carries: erasing both security contexts
renders byte-identical to the defaults.

Left untouched on purpose: the float64 quantity finding (#157), because
multiplyQuantity is the same copy in all 21 charts and a single-chart fix would
create drift, and seccompProfile (#84), which changes runtime behaviour and
belongs in its own change.

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.java8
-appVersion: "2026.8.2-java8"
+version: 4.0.0+up2026.8.2.java17
+appVersion: "2026.8.2-java17"
 
 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-java8".
-  version: "1.12.2"
+  # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java17".
+  version: "1.20.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