The front is the authority for config READS (settings GET, status, queue capacity).
A settings SAVE stays on the engine because it applies live runtime changes
(thermal, RAM monitor, broker runtime) that only exist there and then persists
config.json. The front now detects the config.json mtime change and re-reads it
into self.config IN PLACE (so the supervisor/admin_data references see it), keeping
everything it serves current without a restart. Triggered from status() and the
settings GET handler (via an on_config_read callback) and lazily in the capacity
helper.

This is the pragmatic Phase 2: front owns/serves config; engine applies+persists;
front stays consistent. (Fully relocating the 362-line apply logic to the front
isn't sound — the live application must run on the engine.)

Verified: front reflects an external config.json change (queue_max 6→11) with no
restart.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011DDv7BchtZQWsnPG6Jm49m