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.

minecraft-server/templates/minecraft-server.configmap.yaml

@@ -0,0 +1,49 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: {{ .Release.Name }}-{{ .Chart.Name }}-configmap
+data:
+  init.sh: |
+    set -e
+    echo "downloading serverpack"
+    wget -O /modpacks/serverpack.zip {{ .Values.curseforgeServerpack.downloadUrl }}
+    SERVERPACK_DIR="{{ .Values.curseforgeServerpack.workingDirectory }}"
+    BACKUP_DIR="/data/serverpack-backup"
+
+    if [ -d "$SERVERPACK_DIR" ]; then
+      echo "found installed server. Migrating..."
+      if [ -d "$BACKUP_DIR" ]; then
+        echo "clearing old Backup"
+        rm -rf $BACKUP_DIR
+      fi
+
+      echo "backing up old server-files"
+      cp -r $SERVERPACK_DIR $BACKUP_DIR
+
+      rm -rf $SERVERPACK_DIR
+      mkdir $SERVERPACK_DIR
+
+      echo "extracting new server-files"
+      tar -xvf /modpacks/serverpack.zip -C $SERVERPACK_DIR
+
+      echo "copying old configuration-data"
+      cp -r $BACKUP_DIR/world $SERVERPACK_DIR/world
+      cp $BACKUP_DIR/banned-ips.json $SERVERPACK_DIR/banned-ips.json
+      cp $BACKUP_DIR/banned-players.json $SERVERPACK_DIR/banned-players.json
+      cp $BACKUP_DIR/ops.json $SERVERPACK_DIR/ops.json
+      cp $BACKUP_DIR/whitelist.json $SERVERPACK_DIR/whitelist.json
+
+      # The init container runs as the same uid as the server (see
+      # securityContext.pod) and cp creates the copies owned by that uid, so
+      # this is a no-op in the normal case. It is kept for volumes whose files
+      # still carry a foreign owner from an older chart version, and it must
+      # not be fatal: an unprivileged process cannot chown foreign files, and
+      # with "set -e" a failure here would keep the whole pod from starting.
+      echo "change owner of files"
+      chown -R 1000:1000 $SERVERPACK_DIR || echo "chown skipped (not permitted); continuing"
+
+      echo "successfully migrated server"
+
+      # echo "deleting serverpack.zip"
+      # rm /modpacks/serverpack.zip
+    fi