satisfactory: game.enableSeasonalEvents says what it does (7.0.0+upv1.9.10)

game.seasonalEvents was handed to the container unchanged, into the image's
DISABLESEASONALEVENTS. Its default true therefore wrote
DISABLESEASONALEVENTS=true: the seasonal events were OFF in every install
this chart has ever produced, while values.schema.json described the very
same key as "true means events are enabled" (#215).

Of the two ways out, this is the loud one. Inverting the template under the
old key would have flipped the behaviour of every existing release in
silence - the same class of mistake that created the issue. Renaming the key
cannot be missed: game.seasonalEvents no longer exists, additionalProperties
is false on the game block, and a values file that still carries it fails
schema validation on upgrade instead of quietly meaning the opposite.

The new key is positive (enableSeasonalEvents) to avoid a double negative,
so the chart negates it on the way into the env var. Go's "not" cannot do
that: it reads every non-empty string as true, and the schema deliberately
accepts the string form of booleans, so "false" would have flipped the wrong
way. The helper compares explicitly and fails on anything that is neither
true nor false rather than filing it under "off".

The default is enableSeasonalEvents: false, which renders the
DISABLESEASONALEVENTS this chart has always rendered. At chart defaults the
6.1.0 and 7.0.0 manifests are identical, so upgrading alone moves no server;
switching the events on is now a deliberate act with a key that means it.

Separate finding from the same issue, fixed here because it lives in the
block being touched: "--set game=null" - or a leftover "game:" whose
sub-keys were deleted - aborted the render with a nil pointer at
.Values.game.maxPlayers. The game block never got the null-safe treatment of
#99 that probes, security contexts and resources have. It now falls back to
the documented defaults, and the schema accepts the null accordingly. The
same gap remains in the dev and server blocks; it is reported, not fixed
here.

Major bump: a values key is removed, and the schema rejects it.

satisfactory/values.yaml

@@ -10,7 +10,23 @@ dev:
 game:
   experimental: false
   maxPlayers: 4
-  seasonalEvents: true
+  # Seasonal (holiday) events. The image only knows the negative switch
+  # DISABLESEASONALEVENTS, so the chart NEGATES this value on the way in:
+  # enableSeasonalEvents: true renders DISABLESEASONALEVENTS="false" (events
+  # run), false renders "true" (events off). Only true/false are accepted, in
+  # boolean or string form; anything else aborts the render instead of being
+  # read as one of the two.
+  #
+  # The default is false on purpose, and it is not a preference: it reproduces
+  # what this chart has ALWAYS rendered. Up to 6.1.0 the key was called
+  # game.seasonalEvents and was passed through UNCHANGED, so its default true
+  # wrote DISABLESEASONALEVENTS=true — the events were off in every install,
+  # while values.schema.json claimed "true means events are enabled" (#215).
+  # Keeping the rendered result identical is what makes this rename loud
+  # instead of silent: nobody's server changes behaviour by upgrading, and the
+  # old key is now rejected by the schema, so anyone who set it has to decide
+  # again. Set enableSeasonalEvents: true to actually switch the events on.
+  enableSeasonalEvents: false
 
 server:
   # Replica count for this workload; 0 is allowed and scales it down.