Harden light and dark theme contrast

[ApocDev]

PyOps will keep light, dark, and system themes. The switching mechanism is small and healthy; the remaining work is a focused contrast pass.

Current audit:

• 40 dark: utility tokens across 10 files.
• 33 tokens are concentrated in seven shared UI primitives, one is app-specific, and six are redundant dark:bg-transparent declarations.
• Theme unit tests pass 4/4 and the persistence E2E passes 1/1.
• Desktop and mobile light-mode samples are structurally coherent.
• Light semantic contrast is below the 4.5:1 normal-text target for primary, success, warning, and info. Primary foreground on the orange action color is also below target in both themes.

Implementation:

• Tune the light primary, success, warning, and info tokens to preserve their semantic hues while meeting WCAG AA normal-text contrast on page and low-opacity tinted backgrounds.
• Fix primary action foreground contrast in both themes.
• Verify muted navigation/tab treatments after theme transitions settle.
• Remove the six redundant conditional overrides; keep meaningful shared-primitive dark: variants.
• Add automated computed-style contrast coverage for representative token pairs and rendered routes in light and dark themes.
• Keep the existing light/dark/system selector, pre-paint behavior, persistence tests, and system preference support.
• Update the design documentation with the contrast requirement and verification workflow.

Done when shared semantic text/background pairs meet at least 4.5:1 in both themes, representative rendered UI has no unexplained normal-text contrast failures, theme switching still passes, app/docs checks pass, and desktop/mobile visual smoke review finds no regression.

[ApocDev]

Mechanism shipped (3c00b92): a light/dark/system toggle in Settings → Display, persisted at pyops.theme, applied by lib/theme.ts (toggles .dark + color-scheme, follows the OS while on system), with a pre-paint script in the root document so switching never flashes. Audited the whole codebase for raw-palette leaks — zero (the design-system guard has held), so every surface inherits the light token set. Verified by a unit test (persist/apply/system-resolve) and an e2e (the class + color-scheme flip and survive a reload).

Left open on purpose for the visual pass: light mode is now reachable and wired, but 'does every route read well in light' — contrast, tint balance across the new surfaces (recipe/dependency explorers, the sankey view, IIS cards, the pin editor) — is an inherently visual judgment I can't certify without eyeballing screenshots. Flip it on and nitpick; that's the remaining half. (This also settles the issue's fork: the light tokens aren't dead code to remove — they're live.)