Adopt quadraui Theme/Color and delete vimcode's VS Code theme loader (~650 lines)

[JDonaghy]

Problem

src/render.rs carries its own Color type and a complete VS Code theme loader, then pays to convert both into quadraui's equivalents on every use.

Component	Location	Lines
vimcode's Color (incl. from_hex, lighten, darken)	src/render.rs:29-230	202
Theme::from_vscode_json	src/render.rs:12384-12735	~352
strip_json_comments	src/render.rs:181-229	~49
load_vscode_theme / themes_dir / available_names	src/render.rs:12313-12383	~70
Theme struct + impl	src/render.rs:11162-12848	1,689 (incl. ~940 of preset hex)

quadraui already ships theme.rs (563 lines, 60+ chrome fields) and types::Color with the same from_hex / lighten / darken. The cost of the duplicate type is paid at 62 conversion call sites in render.rs (to_q_color / to_quadraui_color / to_quadraui_theme* at :19675-19777) plus 14 more in the backends.

Two of those conversions are also dead and toolkit-named: Color::to_cairo (:146) and Color::to_pango_u16 (:172) have zero callers — their deletion is covered by the dead-code sweep issue in this chain, not here.

Blocked on quadraui#775

The loader and colour maths are generic and belong upstream; the gap is filed as quadraui#775, requesting Theme::from_vscode_json(path) and Color::try_from_hex_over(hex, bg).

This issue stays open behind quadraui#775 and is deliberately NOT queued. Per GOALS.md's milestone-discipline rule, a supply-blocked #7 issue stays open behind its blocker rather than being closed.

Fix, once quadraui#775 lands

1. Bump the pin.
2. Delete vimcode's Color type; use quadraui::Color throughout. This removes ~76 conversion call sites.
3. Delete from_vscode_json, strip_json_comments and the theme-directory helpers; call the upstream loader.
4. Keep vimcode's syntax-scope fields (scope_color, semantic_token_style) and the preset syntax colours — those are editor-specific and correctly local.

Expected reduction: ~650 lines plus the conversion sites.

Acceptance

• Black-box tests, both backends: load each bundled preset and a VS Code JSON theme, assert rendered chrome colours match before and after.
• Per feedback_no_hardcoded_colors, no hex/RGB literal may appear in rendering code — everything reads from the theme struct.
• State in the PR that the new tests fail against unfixed develop.

[JDonaghy]

Unblocked — now queued

quadraui#775 is merged (✓ MERGED — issue-775-theme-from-vscode-json-color-hex-lighten has landed on develop), so Theme::from_vscode_json and the Color maths this issue needs are upstream. blocked label removed and the issue is queued at the tail of the platform-neutrality chain.

It sits after #811 (the pin bump), so the API arrives in the pinned rev before this is dispatched.

Verify before starting: read the actual signatures that landed in quadraui#775 rather than the ones proposed in this issue body — in particular whether Color::try_from_hex_over shipped under that name and shape. Implement against what landed.

Note that Color::to_cairo / Color::to_pango_u16 are deleted by #812 earlier in this chain, so they should already be gone when you get here.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.