Make Atlas settings config-driven and add an agent self-configuration skill

[uzayer]

Goal

Every user-facing Atlas setting should be inspectable and changeable through a documented configuration file, with the Settings UI and config file remaining in sync. Ship an Atlas-managed skill that lets supported agents discover and safely update that configuration—analogous to Claude Code’s self-update DX.

Current state

• Global UI settings already have a typed AppSettings schema on both sides:
  • src-tauri/src/state/app_state.rs
  • src/features/project/stores/project-store.ts
• Those settings are persisted inside the app-data state.json, through a frontend-built app-state payload.
• Some adjacent configuration is fragmented into dedicated app-config files (for example mcp-servers.json, telemetry config, BYOK storage, and per-project .atlas/ state).
• The existing Skills feature has a canonical managed library and can project a global skill into detected agent config folders (Claude Code, Codex, etc.).

Scope

1. Define a stable, human-editable Atlas configuration format and location for user-facing settings, including schema versioning, documented defaults, validation, and migrations.
2. Make UI changes and config-file edits converge on the same source of truth. External edits must be detected/reloaded safely; malformed or unknown values must not overwrite a working configuration.
3. Add a globally projectable, Atlas-owned self-configure skill that teaches agents how to:
   • locate and inspect the supported Atlas config;
   • explain valid keys and values;
   • make minimal, validated changes through the supported mechanism;
   • preserve comments/unknown fields where the chosen format supports them; and
   • distinguish user preferences from secrets, credentials, session history, and machine-managed state.

Non-goals

• Do not expose API keys, auth/session tokens, telemetry identities, or arbitrary internal runtime/state files as editable “settings”.
• Do not replace per-project document/editor/session state merely because it is file-backed; establish explicit ownership and scope first.
• Do not give the skill permission to update Atlas binaries, packages, or arbitrary files. “Self-update” here means self-configuration.

Acceptance criteria

• A documented config file covers all currently user-facing Atlas preferences, including the existing AppSettings fields and settings added later through a single extension path.
• Atlas loads it at startup, validates it, and surfaces actionable errors without losing the last known-good settings.
• Changes made in Settings update the config atomically; supported external file edits are reflected in the app without a restart where practical (otherwise clearly signal reload/restart).
• Migration from the current state.json settings is lossless and idempotent.
• The config schema/versioning and precedence rules (defaults, config, UI/session overrides, project scope where applicable) are documented.
• A managed global self-configure skill is available for supported Atlas agents and uses only the supported config API/path.
• Tests cover defaults, migration, malformed files, unknown keys, UI/file round trips, and the skill’s discoverability/projection.