[Feature]: Investigate File-Based User Configuration

[esphynox]

Summary

Investigate whether Keyty should support a user-editable file-based configuration in addition to the current app-managed settings storage.

This is separate from export/import settings. The goal here is to evaluate whether Keyty should expose a stable config file contract for advanced users.

Motivation

A file-based config could be useful for:

• power users who prefer text-based configuration
• keeping settings under dotfile management
• moving settings through existing config workflows
• making app setup more reproducible

Questions to answer

• Should this be based on ~/.config, Application Support, or another location?
• Should the file be the primary source of truth or an import/export surface?
• Should the app watch the file and reload changes live?
• How should invalid or partially valid config be handled?
• What is the precedence if both UI changes and file edits modify settings?
• How should schema migrations work over time?
• What support expectations do we want for manual editing?

Technical considerations

• A public config file becomes a long-lived external contract.
• Internal persistence keys should not be exposed directly as the config schema.
• The format would need explicit versioning and migration support.
• Manual edits require strong validation, fallback behavior, and error reporting.
• This should be evaluated against the existing AppSettingsContainer and stored settings architecture.

Out of scope

• implementing export/import settings in this issue
• choosing a final schema before requirements are clarified
• automatic sync between devices

Desired outcome

• Decide whether file-based config is worth supporting.
• If yes, define the preferred model and constraints.
• If yes, identify follow-up implementation issues for schema design, persistence, reload behavior, and UX.