Establish design system and apply it consistently across the app

[NicolaasGrobler]

Problem

The UI has drifted into visible inconsistency as features have piled up:

• Unreadable buttons — some button color combos fail contrast (low-contrast text on tinted backgrounds), making actions hard or impossible to read.
• Inconsistent spacing, radii, and typography between dialogs, the explorer, the editor toolbar, the results grid, and the tools modals.
• Ad-hoc color usage — colors are chosen per-component instead of pulled from a shared token set, so theming and dark/light parity is uneven.
• No premium feel — current treatment reads as "early dev tool" rather than a polished, paid-grade desktop app.

We need to fix this before the surface area grows further — every new feature shipped without a system compounds the cleanup cost.

Proposal

Two-phase effort:

Phase 1 — Design system

Produce a documented design system covering:

• Color tokens — semantic palette (surface, surface-elevated, border, text-primary, text-muted, accent, danger, warning, success, info) with verified WCAG AA contrast pairs for both light and dark themes.
• Typography scale — font family, sizes, weights, line-heights, and where each step is used (heading, body, label, code, caption).
• Spacing scale — single 4px-based scale; eliminate one-off pixel values.
• Radii, shadows, borders — small set of named tokens.
• Component primitives — Button (primary/secondary/ghost/destructive + sizes + disabled/loading), Input, Select, Dialog, Tooltip, Tabs, Menu, Toast, Empty state. Each with documented states.
• Motion — duration + easing tokens for hovers, dialogs, toasts.
• Iconography — single icon set, sizes, stroke width.

Use the lazyweb skill to pull references from premium-feeling desktop/dev tools (Linear, Raycast, Arc, TablePlus, DataGrip, Beekeeper Studio, Postico, Warp, Cursor) so the system is grounded in real-world premium patterns, not generated from scratch.

Deliverables:

• docs/design-system.md (or website docs page) with tokens, component specs, and do/don'ts.
• Tailwind v4 @theme tokens in src/styles/ reflecting the system.
• Reference page in the app under a hidden route or in website/ showing every primitive and state.

Phase 2 — Apply across the app

Sweep the codebase replacing ad-hoc styles with tokens and shared primitives. Suggested order, highest visibility first:

1. Buttons everywhere — fix the unreadable ones first; this is the most-cited pain.
2. Dialogs — ConfirmDialog, connection dialogs, settings, help, tools modals.
3. Toolbar + Sidebar + Explorer — chrome consistency.
4. Editor toolbar + Results grid chrome — work-area consistency.
5. Tools modals — AI assistant, compare, clone, activity monitor, multi-query, definition viewer.
6. Forms — inputs, selects, validation states.
7. Empty / loading / error states across the app.

Each sweep lands as its own PR with before/after screenshots so review stays manageable.

Acceptance criteria

• All interactive elements meet WCAG AA contrast in both themes.
• No component imports raw hex values for color, spacing, or radius — everything flows through tokens.
• Shared Button, Input, Select, Dialog, etc. primitives exist and are used everywhere; per-feature one-offs are gone.
• The app is visibly consistent: pick any two dialogs side-by-side and they read as the same product.
• Premium feel — comparable density, polish, and restraint to the reference set above.

Out of scope

• Full re-skin / brand refresh — this is system + consistency, not a visual identity overhaul.
• Component test coverage (tracked separately in Testing infrastructure roadmap #24).

Notes

• Worth scoping Phase 1 as a single focused PR so the system is reviewable as one artifact before sweeps begin.
• Phase 2 should be milestoned and not rushed into a single mega-PR.