v0.9.0 File-decomposition Phase 1: split config/provider and TUI view surfaces safely

[Hmbown]

Problem

Several CodeWhale files are too large for agents to edit safely. v0.9.0 should reduce slop risk by carving out the most heavily edited surfaces before piling on HarnessProfiles, provider routes, Model Lab, PlanReview, and UI refresh work.

Source of truth

See docs/rfcs/FILE_DECOMPOSITION_0_9_0.md and #2175.

Scope

Phase 1 only. Do not attempt a total rewrite.

Suggested targets:

• crates/tui/src/config.rs
  • provider enum/registry parsing
  • provider defaults/env aliases
  • provider URL/model helpers
  • user settings/config view helpers
• crates/tui/src/tui/views/mod.rs
  • config view rows/actions
  • command/picker view helpers
  • provider/model picker wiring
• crates/tui/src/tui/ui.rs
  • extract self-contained rendering helpers only where tests already exist

Acceptance criteria

• No behavior changes unless explicitly covered by tests.
• Module boundaries make ProviderKind/ApiProvider collapse (Collapse ProviderKind / ApiProvider dual enum behind a Provider trait #2075), HarnessProfile UX (v0.9.0 HarnessProfile UX: show provider, model, profile, and repo law clearly #2703), and Hugging Face provider work (v0.9.0 EPIC: Make Hugging Face a first-class CodeWhale surface #2705-v0.9.0 Direct Hugging Face search commands and picker flow #2712) easier.
• Existing provider registry drift check still passes.
• Existing config/provider tests still pass.
• The split uses local modules with clear names, not new abstractions that hide behavior.
• The PR avoids touching unrelated runtime, release, or provider semantics.

Suggested verification

• python3 scripts/check-provider-registry.py
• cargo test -p codewhale-config --lib
• cargo test -p codewhale-tui --bin codewhale-tui config_command_provider provider_url
• cargo fmt --check