fix(zomboid): re-sync the world settings from the live server

The vendored Sophie preset and the running debbzoid world had drifted, and the
repo only held the preset. That is not a restore point: force-pushing it would
have reverted the admins' in-game tuning rather than recovering it, which is
exactly how a Sophie world quietly became an Apocalypse one once already -- 139
values reverted, loot from 0.35 back to 0.9, CharacterFreePoints 0 to 60.

files/zomboid/sophie/SandboxVars.lua is now a snapshot of the live world taken
2026-08-31, not the preset as shipped. The modlist is untouched and still
upstream, which is why zomboid_preset_version now names the two halves and their
separate dates. server.ini.j2 carries the eight keys that had drifted:

  PlayerSafehouse              false -> true
  SafehouseAllowNonResidential false -> true   (the diner/gas-station case)
  SafehouseAllowRespawn        false -> true
  SafehouseAllowLoot           true  -> false
  SafehouseAllowFire           true  -> false
  TrashDeleteAll               false -> true
  MapRemotePlayerVisibility    1     -> 4
  ResetID                      6953472 -> 826046

ResetID is in that list on purpose, and matters most. It is the world's
soft-reset token: a file value that differs from the one the live world was
created with tells every connected client to roll a new character. Carrying the
live value makes a deliberate force-push a no-op instead of a server-wide wipe
prompt.

Spawn config gets its own switch, zomboid_spawn_force. spawnregions.lua and
spawnpoints.lua are the only config a running world re-reads -- at every server
start, where SandboxVars is read once, when the world is created -- so a spawn
edit is deployable on the live world without a wipe. Sharing zomboid_config_force
between them would have meant force-pushing the whole preset to land a one-line
spawn edit, rewriting the INI (hence the ResetID hazard above) and the world's
SandboxVars along with it.

config-template/ now tracks the repo unconditionally. Nothing on the host writes
that directory and the server cannot see it, so it has no hand edits to protect;
if it does not track the repo it is not a restore point, just an older world's
settings.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016QdWYhwUtwM2NQGukiRh12

ansible/roles/podman/defaults/main.yml

@@ -80,7 +80,12 @@ zomboid_max_ram: 24g
 
 # The modlist itself lives in vars/zomboid_sophie_mods.yml -- 283 mod IDs and
 # 256 workshop items vendored from the upstream Sophie 42 preset.
-zomboid_preset_version: "sophie-42 @ 2026-07-31"
+#
+# The modlist is still the upstream preset. The world settings no longer are:
+# files/zomboid/sophie/SandboxVars.lua is a snapshot of the running debbzoid
+# world taken 2026-08-31, not the preset as shipped. See the seed tasks in
+# containers/home/zomboid.yml.
+zomboid_preset_version: "sophie-42 mods @ 2026-07-31 / live world settings @ 2026-08-31"
 
 # Mods subtracted from the vendored Sophie lists before they reach the INI.
 # Explicit and reasoned so that re-vendoring a newer preset cannot silently
@@ -139,6 +144,19 @@ zomboid_mods_renamed:
 # between world regenerations. Set true to overwrite it from the templates.
 zomboid_config_force: false
 
+# Same switch, narrowed to spawnregions.lua and spawnpoints.lua. They are the
+# only config a running world re-reads (at every server start, unlike
+# SandboxVars, which is read only when the world is created), so a spawn edit
+# can be deployed to the live world without a wipe. It is separate from
+# zomboid_config_force so that landing one is not an excuse to force the INI and
+# SandboxVars over the top of whatever the admins have set in-game.
+#
+#   make deploy TAGS=zomboid-conf -e zomboid_spawn_force=true
+#
+# The server still has to be restarted, with players offline, before the new
+# spawn config is read.
+zomboid_spawn_force: false
+
 sshpass_cron_path: "{{ podman_volumes }}/sshpass_cron"
 caddy_path: "{{ podman_volumes }}/caddy"