v0.8.63: Split config modules and centralize provider lookup tables

[Hmbown]

Problem

The TUI config layer and shared config crate have large provider/config monoliths:

• crates/tui/src/config.rs
• crates/config/src/lib.rs

The analysis found duplicated provider match blocks around a 25-variant provider enum. Adding a provider requires updating multiple synchronized functions, which increases bug risk.

This overlaps with #2608, which already tracks extracting the provider registry from ballooning config files. This issue should either build on #2608 or become the implementation plan for closing it.

Proposed shape

For crates/tui/src/config.rs, extract focused modules such as:

• config/constants.rs
• config/provider.rs
• config/model_names.rs
• config/types.rs
• config/loading.rs
• config/env_override.rs
• config/paths.rs
• config/workspace_trust.rs
• config/credentials.rs

For crates/config/src/lib.rs, extract:

• provider/model constants
• TOML schema/types
• migration/compatibility code
• provider registry/metadata lookup
• tests

Provider registry direction

Replace repeated match ApiProvider / match ProviderKind blocks with a single lookup-table/metadata accessor where possible. Provider-specific behavior can still exist, but the common metadata should not be duplicated across 5+ functions.

Acceptance criteria

• Provider metadata has one authoritative source for common fields.
• Existing provider defaults and env override behavior remain compatible.
• Config TOML serde round-trip tests cover all provider variants.
• Legacy aliases and migration behavior remain tested.
• Refactor: extract provider registry from ballooning config files #2608 is linked, closed, or updated to point to the new implementation issue.
• No provider route/model compatibility regression.

Risk

Medium. This needs compatibility tests before deeper module surgery.