Bring minecraft-server up to the chart style guidelines (1.0.0+upjava8)

Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime
behaviour changes (probes, hardening) and the values interface breaks
(resource renames, strict schema).

Two real bugs first:
- The container declared port 35565 while the Service targeted 25565. It
  only worked because targetPort was numeric. Both are now server.port
  (25565) and the Service targets the named port.
- The download-serverpack init container was guarded by the map
  .Values.curseforgeServerpack instead of .enabled, so it rendered for
  every release and silently no-opped on an empty wget URL.

Conventions:
- Resources renamed to <release>-<chart>-<kind>, templates to
  <app>.<kind>.yaml. The PVC deliberately keeps its historical name -
  renaming it would provision a new, empty volume and orphan the worlds.
- Probes (liveness/readiness/startup) via the image's own mc-health, so
  Ready means the server answers a server-list ping. Startup budget 20 min.
- Hardened, values-configurable security contexts: non-root uid 1000,
  read-only root filesystem with an emptyDir at /tmp, all caps dropped.
- Resources from values with the limitFactor helper; an unset memory
  request is derived from the JVM heap so the two cannot drift apart.
- Additive env block rendered through tpl, pinned init image, storage
  class as a value, RCON wiring only when actually enabled.
- curseforge/ftb/curseforgeServerpack are now mutually exclusive.
- minecraft.version is pinned to the Java line instead of LATEST.
- The mc-router auto-discovery annotation is gone; the service type it
  implicitly switched is now the explicit value server.service.type.

Schema pilot (#68): values.schema.json with additionalProperties false on
every chart-owned level, rejecting all three known dead keys.

ci/minecraft-server/fixtures.yaml

@@ -62,8 +62,10 @@ spec:
 apiVersion: v1
 kind: Secret
 metadata:
-  name: ci-mc-secret
+  name: ci-minecraft-server-secret
 stringData:
+  # Only consumed when server.rcon.enabled is true (RCON is off by default, and
+  # since chart 1.0.0 the chart no longer references the key while it is off).
   rcon-password: ci-dummy-rcon-password
   # Only consumed when curseforge.enabled is true; provided so the CI install
   # keeps working if the test values ever enable a CurseForge modpack.

ci/minecraft-server/test-values.yaml

@@ -1,33 +1,21 @@
 # Values for the minecraft-server install-test. Kept as close to the real
 # deployments as possible; only what a CI runner cannot provide is overridden.
 #
-# 1. minecraft.version: the image tag comes from .Chart.AppVersion, so the JVM
-#    in the image is fixed per published chart version and the Minecraft
-#    version has to match that Java line - Java 8 runs Minecraft only up to
-#    1.16.5, 1.18-1.20.4 need Java 17, and 1.20.5+ need Java 21. No single
-#    Minecraft version boots on all three lines, so this value is bumped
-#    together with appVersion in every Java-line PR.
-#    This chart version publishes appVersion "java21", hence 1.21.1 - which is
-#    also what ftb-skies-2, the one server actually running on this line, sets
-#    in its real values file, so CI exercises the production version rather
-#    than an arbitrary Java-21-capable one.
-#    The production default is "LATEST", which would drift on every restart.
-# 2. minecraft.resources.storage: the production 32Gi world volume is backed by
-#    a static hostPath PV in CI (see fixtures.yaml); 2Gi is plenty for a server
-#    that only has to boot.
-# 3. minecraft.resources.memory: sets the JVM heap (-Xmx); 1G instead of 4G
-#    keeps the runner comfortable. The container resource *requests* are
-#    hardcoded in the template (cpu 2 / memory 4Gi) and cannot be overridden -
-#    they fit a 4-vCPU/16GB GitHub runner, and making them configurable is part
-#    of the stage-2 convention alignment.
-# 4. server.outwardPort stays at the chart default 30565: unlike minecraft-router
-#    that default is already inside the Kubernetes node-port range
-#    (30000-32767), so the k3d API server accepts it unchanged.
+# minecraft.version is deliberately NOT set here any more. Since chart 1.0.0 the
+# chart ships a pinned default that belongs to the Java line it publishes (the
+# image tag comes from .Chart.AppVersion, and Java 8 runs Minecraft only up to
+# 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21). Leaving it unset
+# means the install-test exercises exactly the default a user would get, so a
+# Java line published with a mismatched default version fails CI instead of
+# passing on a CI-only override.
+#
+# server.service.type is not set either: the default is ClusterIP, which is what
+# all three real deployments run (routing is done by the static mappings of the
+# minecraft-router chart). That also keeps CI free of node-port allocation.
 secrets:
   minecraftServerRef: vaults/CI/items/minecraft-server
 
 minecraft:
-  version: "1.21.1"
   management:
     # opPlayers deliberately stays at the default (null): the image resolves
     # every name in OPS against the external Playerdb API and aborts the whole
@@ -36,5 +24,19 @@ minecraft:
     # lookup.
     maxPlayers: 2
   resources:
+    # The production 32Gi world volume is backed by a static hostPath PV in CI
+    # (see fixtures.yaml); 2Gi is plenty for a server that only has to boot.
     storage: 2Gi
+    # JVM heap. 1G instead of 4G keeps the runner comfortable - and since chart
+    # 1.0.0 this also drives the container's memory request (1Gi) and, via
+    # limitFactor 3, its limit (3Gi), so the runner is not asked for the
+    # production-sized 4Gi/12Gi any more.
     memory: "1"
+
+server:
+  resources:
+    requests:
+      # The production default is 2 CPUs, which would not leave much room on a
+      # 4-vCPU GitHub runner alongside the k3d control plane. Since chart 1.0.0
+      # this is configurable instead of hardcoded in the template.
+      cpu: "500m"