Theming foundation: extract all hardcoded colors into a swappable theme module

[Harry-kp]

Context

This evolves #109 (replace hardcoded colors) from a mechanical refactor into a feature foundation. Instead of just moving colors to constants, we build the infrastructure for user-selectable themes.

User Story

As a contributor, I want all colors in one place so I can add a new theme without touching 13 files. As a user, I want Vortix to look good in both dark and light terminals.

Design

Phase 1 (v0.1.8): Foundation

• All Color::Rgb(...) in src/ui/ → theme::current().panel_border etc.
• Theme struct with named semantic colors (not "blue" but "panel_border", "active_indicator", "warning_text")
• Default theme: current Nord-inspired palette
• theme::current() returns a static reference to the active theme

Phase 2 (future): User Selection

• theme field in config.toml
• Built-in themes: Nord, Dracula, Solarized Dark, Solarized Light
• Runtime theme switching

Implementation (Phase 1 only)

Step 1: Define the Theme struct in src/theme.rs:

pub struct Theme {
    pub panel_border: Color,
    pub panel_border_focused: Color,
    pub text_primary: Color,
    pub text_secondary: Color,
    pub text_dim: Color,
    pub accent: Color,
    pub success: Color,
    pub warning: Color,
    pub error: Color,
    pub connected_badge: Color,
    pub sidebar_selected: Color,
    pub header_bg: Color,
    // ... etc
}

pub const NORD: Theme = Theme { ... };

pub fn current() -> &'static Theme {
    &NORD  // For now, always Nord. Phase 2 makes this configurable.
}

Step 2: Replace all Color::Rgb(...) in src/ui/**/*.rs with theme::current().field_name.

Step 3: Verify: rg "Color::Rgb" src/ui/ returns zero results.

Acceptance Criteria

• Theme struct with semantic color names
• All UI colors reference theme::current()
• Zero Color::Rgb calls in src/ui/
• Visual appearance unchanged (same palette, just referenced differently)
• Adding a new theme = adding one const Theme block

Supersedes

Closes #109 when merged.