Summary

Refactor agents, departments, and providers API endpoints to read from SettingsService via JSON-type settings instead of directly from RootConfig. This makes structural org data (agent roster, department hierarchy, provider configs) editable at runtime through the DB/API without YAML edits or restarts.

Context

Issue #497 migrates scalar config consumers (budget limits, coordination topology, autonomy level, etc.) to SettingsService. However, structural data endpoints still read directly from app_state.config:

• api/controllers/agents.py → app_state.config.agents (tuple of AgentConfig)
• api/controllers/departments.py → app_state.config.departments (tuple of Department)
• api/controllers/providers.py → app_state.config.providers (dict of ProviderConfig)
• api/controllers/company.py → config.agents, config.departments
• api/controllers/analytics.py → len(config.agents)

These are complex nested Pydantic models that don't map to individual scalar settings. They need JSON-type SettingDefinition entries in the registry.

Scope

• Add JSON-type settings: company/agents, company/departments, providers/configs
• Enhance config_bridge.extract_from_config() to serialize Pydantic models and dicts/lists as JSON (currently uses str() which produces repr, not valid JSON)
• Add ConfigResolver methods: get_agents(), get_departments(), get_provider_configs() that deserialize JSON back to typed Pydantic models
• Migrate the 5 controller files listed above
• Update corresponding tests

Blocked By

• feat: migrate existing config paths to read through SettingsService #497 (creates the ConfigResolver infrastructure this builds on)

Related

• feat: implement provider management (multi-auth, runtime CRUD, local providers) #451 (provider runtime CRUD — complementary, that adds write endpoints)