minecraft-server: null-safe hardening, probes and resources

The last open gap of #99. minecraft-server was the one chart of 21 where an
erased security context removed the hardening in silence: it never got the
defaultedDict helper, the StatefulSet rendered .Values.securityContext.pod
straight through toYaml, and the schema typed securityContext.pod as a strict
"object" without required. Measured against ci/minecraft-server/test-values.yaml
on 3.0.1:

  --set securityContext.pod=null --set securityContext.container=null
  -> helm exit 0, no schema error, "securityContext: null" for BOTH the pod and
     the container - no runAsNonRoot, no readOnlyRootFilesystem, no dropped
     capabilities, in a chart with a PVC.

Bitter place for it: the README lists this chart as the pilot for #68. It got
its schema early and was therefore never caught by the later null-safety wave.

Both halves are added, because they cover different cases. For a key WITH a
chart default Helm's coalescing deletes the null before validation ever sees
it, and only the defaultedDict fallback catches that; for a key WITHOUT one
(server.resources.limits) the null survives into validation, where the strict
"object" aborted the render. Now widened to ["object","null"].

The fallback table reproduces THIS chart's defaults, deviations included:
uid/gid pinned to 1000 (the image's minecraft user - starting as it directly
takes the entrypoint's non-root branch, which skips the recursive chown of
/data and the write to /etc/nsswitch.conf that a read-only root filesystem
would reject), fsGroupChangePolicy OnRootMismatch (a recursive chown of a 32Gi
world on every start costs minutes), the explicit empty capabilities.add list,
and all three probes as exec probes running the image's mc-health script - this
image has no HTTP endpoint, so a probe default rebuilt as httpGet would leave
the workload with no working probe at all. The startup budget stays 15s x 80.

server.resources goes through the same helper while keeping its memory request
deliberately unset, so it is still derived from the JVM heap.

Also, the same class one level down: init.sh chowned the migrated serverpack to
a hardcoded 1000:1000 while the uid it has to match was overridable. Both reads
now go through the same helper, so they cannot disagree. With the chart defaults
the rendered script is unchanged, so checksum/config does not move and no
existing pod rolls.

minecraft.resources.storage and .memory stay deliberately not null-safe: an
erased value yields an invalid PVC or an unparseable quantity, which is the loud
class #99 excludes.

Evidence, all against ci/minecraft-server/test-values.yaml unless noted:

  - the reported call now renders the defaults, byte-identical to the
    unmodified rendering. Fallback, not rejection.
  - rendering with securityContext, all three probes and server.resources set
    to null is byte-identical to rendering the chart defaults - which is what
    keeps the table and values.yaml in sync instead of leaving it to discipline.
  - no regression: rendering before and after the change is byte-identical, on
    the CI values, on the chart defaults, and with curseforgeServerpack enabled
    (the init-container path the CI values do not exercise). Confirmed
    structurally too, not only by raw diff.
  - partial nulling, 14 keys swept one at a time. On 3.0.1 twelve of them
    changed the rendering silently, including capabilities (the container kept
    every default capability instead of dropping ALL) and requests (cpu and
    ephemeral-storage disappeared entirely). On 4.0.0 all fourteen render
    identical to the defaults.
  - explicit false and 0 still win over the defaults; a scalar in a mapping slot
    is still rejected, now naming the values path.

Major bump: erasing one of these blocks used to change the rendered workload
and now does not, which is a runtime behaviour change. appVersion is untouched.

Refs #99

minecraft-server/values.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json-schema.org/draft-07/schema#",
   "title": "minecraft-server values",
-  "description": "Strict values schema (issue #68 pilot). additionalProperties is false on every chart-owned object level, so a key that the chart does not read is rejected at render time instead of being silently ignored. The only objects that stay open are the ones passed verbatim into the Kubernetes pod spec (probes, security contexts, global) - the chart does not interpret their contents, so it cannot judge which keys are meaningful.",
+  "description": "Strict values schema (issue #68 pilot). additionalProperties is false on every chart-owned object level, so a key that the chart does not read is rejected at render time instead of being silently ignored. The only objects that stay open are the ones passed verbatim into the Kubernetes pod spec (probes, security contexts, global) - the chart does not interpret their contents, so it cannot judge which keys are meaningful. The hardening, probe and resources blocks additionally accept null, because an erased block falls back to the chart defaults (issue #99). Both halves are needed and cover different cases: for a key WITH a chart default Helm's coalescing deletes the null before validation ever sees it, and only the defaultedDict fallback in _helpers.tpl catches that; for a key WITHOUT one (e.g. server.resources.limits) the null survives into validation, where a strict \"object\" would abort the render. Everything else stays strictly typed.",
   "type": "object",
   "additionalProperties": false,
   "properties": {
@@ -75,7 +75,8 @@
           "type": "string"
         },
         "resources": {
-          "type": "object",
+          "description": "May be null / empty: the chart then falls back to its default requests and computed limits (issue #99) instead of rendering the server container without resource accounting. The memory request stays deliberately unset in that fallback, as in values.yaml, so it keeps being derived from the JVM heap (minecraft.resources.memory).",
+          "type": ["object", "null"],
           "additionalProperties": false,
           "properties": {
             "limitFactor": {
@@ -130,16 +131,17 @@
       "$ref": "#/definitions/probe"
     },
     "securityContext": {
-      "type": "object",
+      "description": "May be null / empty at any level: the chart then falls back to its hardening defaults (issue #99) instead of rendering an unhardened workload. The pod context is consumed twice - as the pod's securityContext and by the serverpack init script, which chowns the migrated files to runAsUser:runAsGroup; both reads go through the same helper.",
+      "type": ["object", "null"],
       "additionalProperties": false,
       "properties": {
         "pod": {
-          "description": "Rendered verbatim as the pod's securityContext; kept open because the chart does not interpret it.",
-          "type": "object"
+          "description": "Merged onto the chart's pod hardening defaults and rendered as the pod's securityContext; kept open because the chart does not interpret the individual fields.",
+          "type": ["object", "null"]
         },
         "container": {
-          "description": "Rendered verbatim as the container's securityContext; kept open because the chart does not interpret it.",
-          "type": "object"
+          "description": "Merged onto the chart's container hardening defaults and rendered as the securityContext of the server container and the serverpack init container; kept open because the chart does not interpret the individual fields.",
+          "type": ["object", "null"]
         }
       }
     },
@@ -283,7 +285,7 @@
   },
   "definitions": {
     "resourceList": {
-      "type": "object",
+      "type": ["object", "null"],
       "additionalProperties": false,
       "properties": {
         "cpu": {
@@ -314,8 +316,8 @@
       }
     },
     "probe": {
-      "description": "Rendered verbatim as a container probe; kept open because the chart does not interpret it.",
-      "type": "object"
+      "description": "Merged onto the chart's probe defaults and rendered as a container probe; kept open because the chart does not interpret the individual fields. May be null / empty, which means the defaults apply (issue #99) rather than the probe disappearing. The defaults carry the probe's context, not just its timings: all three run the image's mc-health script as an exec probe, which is the only health check this image offers.",
+      "type": ["object", "null"]
     }
   }
 }