architecture: rethink config loading system and config files

Problem

Mecatl's configuration system has grown from several legitimate needs, but its current ownership model is difficult to reason about:

• command roots parse flags and some environment/auth-file inputs;
• app.Build constructs and reads/resolves operator settings through permconfig;
• per-workspace, trust-gated project configuration must resolve after a session workspace is known;
• provider and MCP credentials have different loading/lifecycle seams;
• some settings are load-time snapshots while others are re-resolved or refreshed.

This makes it unclear which settings are process-static, which can safely become live-reloadable, and where a Kubernetes/database-backed configuration source should attach.

Goal

Design a coherent configuration architecture that separates:

1. source acquisition — CLI flags, environment, operator files, auth files, Kubernetes ConfigMaps/Secrets, database/remote sources;
2. process-wide operator resolution — typed validation and explicit per-field precedence/merge policy;
3. workspace/session resolution — trust-gated project settings that must remain dependent on a workspace root;
4. runtime composition — app.Build consumes resolved configuration and injected resolvers/loaders rather than owning file-source selection.

The design must classify each configuration subtree as one of:

• process-static / restart required;
• reloadable atomically at runtime;
• per-session/per-workspace resolved;
• credential lifecycle-managed.

It should define safe live-reload semantics: validation before swap, last-known-good behavior, diagnostics, atomicity, which resources are rebuilt or retained, and security/trust constraints. It must preserve existing non-generic merge policies such as deny dominance, operator-only settings, CLI precedence, secret separation, and provider endpoint precedence.

Non-goals

• Replacing the system opportunistically inside the operator-defined-provider PR.
• A generic YAML overlay that erases security/trust-specific merge rules.
• Making secrets available in ordinary settings.yaml.
• Claiming every setting can be live reloaded.

Starting evidence

• internal/adapter/permconfig combines user-global/operator and per-workspace project configuration.
• internal/app.Build constructs the resolver and folds several operator subtrees.
• internal/cliconfig resolves command-side flags, environment, auth-file snapshots, and profile loaders.
• Provider profile loading now has an injected composition seam, while MCP already has a profile-loader/lifecycle seam.
• docs/configuration-reference.md documents schema keys, but not a cross-root effective-configuration or reloadability model.

Related

• #771 — mecated/mecatui configuration ownership and defaults
• #772 — user-facing cross-product settings guide
• ADR 0016 — multi-provider composition
• ADR 0237 — operator-defined LLM providers

Start by reading internal/adapter/permconfig, internal/app.Build, internal/cliconfig, and docs/configuration-reference.md, then review ADR 0016 and ADR 0237. Done means documenting a coherent ownership model that classifies configuration subtrees, preserves existing precedence and trust rules, and specifies validation, reload, diagnostics, atomicity, and resource-lifecycle semantics.