The core-owned write path for game config a loader declares.

A loader - the Lua bundle loader in asobi_lua_config, or anything else that reads a game's own declaration - hands the whole config term to apply_config/1 and never writes asobi's application environment itself. This module decides what the effective registry ends up looking like, and in which order the keys are written.

Two mode layers, one merge

Game modes come from two independent sources, kept in two application-env keys so neither source can clobber the other:

1. game_modes - the operator layer, declared in sys.config. asobi never writes this key.
2. script_game_modes - the script layer, the complete set of modes the currently loaded game declares. apply_config/1 replaces that set wholesale, so a mode deleted from config.lua is gone after the next load instead of surviving forever.

modes/0 composes the two in that order: the script layer first, the operator layer on top. An operator mode therefore wins a name clash, and no bundle reload can redefine or drop it. Every reader goes through modes/0.

guest_auth is replaced, not merged

guest_auth is the game's half of ADR 0004's two-key AND (the operator owns the pepper), so a declared value simply replaces the current flag. It is written before the modes so a reader waking on the mode change already sees the final auth posture.

registration is a second layer, like the modes

A game may declare a signup posture, which lands in script_registration - never in registration, the operator's key from sys.config. asobi_registration composes the two the same way modes/0 does: the operator layer wins whenever it is set. That is what lets an engine-hosted game with no sys.config of its own pick a posture (asobi_lua#122) without letting a game bundle widen an operator's closed deployment back to open.

A term that omits a key leaves that key alone: apply_config(#{modes => M}) is how the config watcher refreshes mode shape without letting a bundle write flip auth posture at runtime.