theme: make ThemeStyle and StatusColors fields constructable

[glani]

Summary

Widens four field-level privacies in crates/ui/src/highlighter/registry.rs:

• ThemeStyle.color, ThemeStyle.font_style, ThemeStyle.font_weight → pub
• StatusColors.error → pub

No semantic change. No signature change. No test change. 4 lines.

Why

HighlightThemeStyle exposes its syntax: SyntaxColors and status: StatusColors as pub fields, and SyntaxColors's per-category fields are pub Option<ThemeStyle>. A downstream consumer can read theme.highlight_theme.style.syntax.keyword and even assign a Some(_) to it — but cannot construct the ThemeStyle value to put inside the Some. The fields are private, no constructor exists, no Default impl exists, only Serialize/Deserialize derives.

The result: programmatic construction of a ThemeStyle from outside the crate is impossible without a JSON round-trip through serde. That's brittle (no compile-time check on field names — a future field rename silently breaks downstream at runtime) and pulls a serde_json dep into consumers who otherwise wouldn't need it.

Two consistency arguments for widening:

1. The wasm_stub.rs counterpart already declares ThemeStyle with all pub fields (crates/ui/src/highlighter/wasm_stub.rs:118-123). Native registry.rs is the outlier — same logical type, different visibility surface depending on target.
2. The encapsulation isn't load-bearing. No validation, no normalization, no invariant. The fields are plain Option<...> config slots that get populated by deserialization and read by From<ThemeStyle> for HighlightStyle. Widening privacy doesn't bypass anything.

Concrete downstream use case

A theme-bridge that maps an app-defined htheme format's syntax.* block onto upstream's SyntaxColors:

let mut highlight = HighlightTheme::clone(&theme.highlight_theme);
let syntax = &mut highlight.style.syntax;

if let Some(s) = htheme.syntax.get("keyword") {
    syntax.keyword = Some(ThemeStyle {
        color: Some(s.fg),
        font_weight: s.bold.then_some(FontWeightContent::Bold),
        font_style: s.italic.then_some(FontStyle::Italic),
    });
}
// ... map remaining categories ...

highlight.style.status.error = Some(htheme.error_color);
theme.highlight_theme = Arc::new(highlight);

Without this PR the same code path requires serde_json::from_value(...) on a hand-built JSON object, which is a workable workaround but is strictly worse on every axis.

Scope deliberately small

The remaining StatusColors fields (warning, info, success, hint and their .background / .border variants) stay private for now. They have the same encapsulation defect, but I've narrowed this PR to exactly the fields a real consumer needs to write today. Happy to widen the scope if you'd prefer all 15 in one go — just say the word.

Status: draft

Marking draft until the downstream consumer (a heretic theme bridge in another workspace) verifies the patch enables the intended use case end-to-end. Will move to ready-for-review once that lands.