Summary

Migrate all existing config consumers (budget, security, providers, etc.) to read through SettingsService instead of directly from RootConfig. This is acceptance criterion 8 from issue #450, deferred from PR #495 due to scope.

Context

PR #495 implemented the settings persistence layer with:

• SettingsService with 4-layer resolution (DB > env > YAML > code defaults)
• SettingsRegistry with 8 namespace definition modules
• config_bridge.py with YAML path resolution
• REST API endpoints

The infrastructure is in place — this issue covers the actual migration of call sites.

Acceptance Criteria

• All config consumers use SettingsService.get() instead of direct RootConfig attribute access
• RootConfig becomes a "defaults provider" only — not the sole config source
• Existing behavior is preserved (tests pass with same config values)
• Migration is incremental — can be done module by module

Related

• Closes criterion 8 of feat: implement settings persistence layer (DB-backed config) #450 (deferred from PR feat: implement settings persistence layer (DB-backed config) #495)

Audit Targets (from #453)

Files that currently read from YAML-loaded config (full audit needed at implementation time):

What Stays as YAML

• Template definitions (templates/) — content/blueprints, not user settings
• Default values — YAML files become "factory defaults" in the resolution chain
• Schema definitions — Pydantic models remain, populated from SettingsService instead of directly from YAML

What Moves to DB

• All provider configuration (keys, URLs, models, retry config)
• Company configuration (name, agents, hierarchy, budgets)
• Memory backend configuration
• Coordination configuration
• Observability settings (log level, sinks)
• Security settings (trust strategies, autonomy levels)
• Any per-agent overrides

Additional Acceptance Criteria (from #453)

• Full audit of every YAML config read path
• DB overrides take precedence over YAML defaults
• No config change requires a YAML edit + restart
• Templates (content) remain as YAML files — only template settings move to DB
• Existing YAML configs still work as defaults (backward compatibility)