Fix settings endpoint secret exposure

[cursor]

Bug and impact

reload_settings() overlays Supabase credentials from environment variables into the runtime settings object. GET /settings returned that object verbatim, so a hosted deployment could expose SUPABASE_SERVICE_ROLE_KEY to anyone who can reach the settings endpoint. The same runtime object was also written by save_settings(), so any settings-writing endpoint could persist env-sourced credentials into config/settings.json.

Root cause

Runtime settings and persisted settings shared the same mutable dictionary, with no redaction before API responses and no stripping of env-sourced secret values before JSON writes.

Fix

• Added redact_settings_for_client() and used it in GET /settings.
• Updated save_settings() to preserve runtime access to env credentials while replacing env-sourced Supabase secret values with the existing persisted value (or empty string) before writing settings.json.
• Added focused loader and router tests covering redaction and non-persistence of env secrets.

Validation

• python3 -m unittest tests.test_settings_router tests.test_settings_loader.SettingsSecretHandlingTests ✅
• python3 -m py_compile config/settings_loader.py routers/settings.py tests/test_settings_loader.py tests/test_settings_router.py ✅

Note: python3 -m unittest tests.test_settings_loader tests.test_settings_router also surfaced an unrelated existing failure: ProfileSettingsTests.test_profile_overrides_defaults expects gemma4:e4b, while config/profiles/local-laptop-gemma.json currently contains gemma3:4b. The router module also required installing minimal runtime dependencies (fastapi, httpx) in this stripped environment.