satisfactory: server.storage stays the documented exception (#39)

Walks back the one part of the previous commit that changed rendered output:
storage was pulled into the server fallback, so an erased size fell back to
20Gi instead of rendering a PVC without one.

values.schema.json had documented the opposite decision - "an erased value
yields an invalid PVC rather than a silently degraded workload" - and that is
someone's reasoned trade, not collateral of the nil-pointer bug next to it.
Overturning it inside a patch would have made this the only release where
valid values render differently, and it would have settled an open design
question in a PR nobody opened for that. It goes to #39 instead.

So storage is out of the defaults again and the schema note is restored
verbatim, extended only by where the exception is argued. values.yaml marks
it as the one key of the block that is deliberately not null-safe. The
README rule that had leaned on this example now says the thing that actually
holds: an exception is fine, an unmarked one is not.

Everything else stands - dev and server null-safe, the single-key findings on
the ports, formatNumber against exponential notation, 7.0.1.

Re-measured after the walk-back: rendered output against the chart defaults
and against a full override set is byte-identical to 7.0.0, NOTES.txt
included, and "--set server=null" now renders exactly the sizeless PVC that
"--set server.storage=null" rendered on 7.0.0.

satisfactory/templates/_helpers.tpl

@@ -333,15 +333,25 @@ The effective server block (Gitea issue #16, the rest of #99).
 single erased sub-key was worse than that: it rendered silently. A nulled
 server.gamePort produced a Service with "port:" and "nodePort:" empty and a
 StatefulSet with an empty containerPort — a manifest the API server rejects
-only at apply time — and a nulled server.storage produced a PVC asking for no
-size at all. Both now fall back to the documented defaults instead.
+only at apply time. Those now fall back to the documented defaults instead.
 
-Note what is NOT defaulted here: server.resources. That block already runs
-through satisfactory.effectiveResources, which carries its own defaults and is
+TWO keys are deliberately NOT defaulted here.
+
+server.resources, because it already runs through
+satisfactory.effectiveResources, which carries its own defaults and is
 null-safe on its own; repeating limitFactor/4Gi/1/5Gi here would create a
-third place for them to drift apart. Keys the defaults do not mention are
-passed through by satisfactory.defaultedDict unchanged, so an erased
-"server:" simply leaves resources unset and effectiveResources supplies them.
+third place for them to drift apart.
+
+server.storage, because values.schema.json documents the opposite decision
+for it on purpose: an erased size must yield an invalid PVC that fails at
+apply time rather than a workload quietly sized by the chart. An erased
+"server:" therefore still renders a PVC without a size — deliberately, not by
+oversight. That exception is worth re-examining, but it is someone's reasoned
+decision and not a bugfix's to overturn; it is negotiated in Gitea issue #39.
+
+Both rely on the same mechanic: keys the defaults do not mention are passed
+through by satisfactory.defaultedDict unchanged, so an erased "server:" leaves
+them unset and whatever consumes them downstream decides what that means.
 
 The defaults below MUST stay in sync with the server block in values.yaml,
 which stays the documented, user-facing place for them; this copy is only the
@@ -351,8 +361,7 @@ fallback for the case where an override has erased the block.
 {{- $defaults := dict
       "replicas" 1
       "gamePort" 30777
-      "messagingPort" 30888
-      "storage" "20Gi" -}}
+      "messagingPort" 30888 -}}
 {{- include "satisfactory.defaultedDict" (dict "defaults" $defaults "given" . "path" "server") -}}
 {{- end -}}