refactor(config): config package imports tui/styles — layering violation

[jongio]

Summary

The internal/config package imports internal/tui/styles to reference the styles.ColorScheme type used in the Config.Schemes field. This inverts the expected dependency direction and is a layering violation.

Current dependency graph (simplified)

Package	Imports
internal/platform	(none — foundational)
internal/data	internal/platform
internal/config	internal/platform, internal/tui/styles ← violation
internal/copilot	internal/data
internal/tui	internal/config, internal/copilot, internal/data, internal/platform

Problem

internal/config is a foundational layer consumed by internal/tui and other packages. Foundational packages must not depend upward on the UI layer. The current arrangement means:

• Any change to internal/tui/styles forces a recompile of internal/config and every package that imports it.
• The conceptual model is violated: configuration is a lower-level concern than terminal styling.
• Adding new packages that need config but not the TUI brings in the full TUI/styles dependency graph transitively.

Location

• internal/config/config.go line 18: "github.com/jongio/dispatch/internal/tui/styles"
• The Config.Schemes field is typed as []styles.ColorScheme

Suggested fix

Move styles.ColorScheme (and its validation helpers) into a shared package — for example internal/colors or internal/theme — that neither config nor tui owns. Both internal/config and internal/tui/styles then import from that shared package. This resolves the upward dependency without changing the public API of either package.

Alternatively, redefine ColorScheme directly in internal/config and convert in the styles layer, keeping config free of TUI imports.

[jongio]

Consolidated into a single tracking issue.