Pin minecraft-server to dated image tags and fix the whitelist switch (2.0.0+up2026.8.2.java8)

Stage 3 of the Fleet migration. Two changes, both breaking, hence the major
bump from 1.0.0 to 2.0.0.

Dated image tags: appVersion moves from the rolling line tag "java8" to the
immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt
continuously, so a pod restart could pull a different image than the previous
start without that being recorded anywhere. 2026.8.2 is the newest upstream
release (published 2026-08-23) and exists for all three Java lines.

Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST)
in both positions, so minecraft.whitelist.enabled: false actually switches the
whitelist off. Previously the chart only emitted whitelist variables while
enabled was true and had no way to express "off" - and because server.properties
lives on the PVC, a release that had once written white-list=true kept it
forever. players stays guarded by enabled, since a non-empty WHITELIST enables
the whitelist in the image regardless of ENABLE_WHITELIST.

The default flips from enabled: true to enabled: false. Under the corrected
semantics the old default (enabled with an empty player list) would mean a
server nobody can join; false matches both the image and vanilla Minecraft.

minecraft-server/templates/minecraft-server.sfs.yaml

@@ -68,6 +68,25 @@ spec:
               value: {{ .Values.minecraft.difficulty }}
             - name: SERVER_PORT
               value: "{{ .Values.server.port }}"
+            # ENABLE_WHITELIST is set in both positions on purpose - it is the
+            # only variable that can switch the whitelist OFF again. The image
+            # enables the whitelist when WHITELIST/WHITELIST_FILE is non-empty
+            # OR ENABLE_WHITELIST is true, and disables it (white-list=false)
+            # when ENABLE_WHITELIST is false, rewriting an existing
+            # server.properties on the volume. Because a non-empty WHITELIST
+            # wins over ENABLE_WHITELIST=false, players must stay unset while
+            # disabled - hence the guard below rather than emitting both.
+            - name: ENABLE_WHITELIST
+              value: "{{ .Values.minecraft.whitelist.enabled }}"
+            # enforce-whitelist is mapped from ENFORCE_WHITELIST in the image's
+            # property-definitions.json. The image only ever sets it to true (in
+            # its enable branch) and never resets it, so without this line a
+            # server that once had the whitelist on keeps enforce-whitelist=true
+            # in its persisted server.properties after switching off. It is
+            # inert while white-list=false, but leaving stale state behind is
+            # exactly what this chart version fixes, so it follows the switch.
+            - name: ENFORCE_WHITELIST
+              value: "{{ .Values.minecraft.whitelist.enabled }}"
             {{- if .Values.minecraft.whitelist.enabled }}
             - name: EXISTING_WHITELIST_FILE
               value: {{ .Values.minecraft.whitelist.overridePolicy }}