Improve theme color contrast with semantic tokens

[Ray0907]

Summary

• introduce readable --text-secondary tokens for all 12 built-in and
  standalone themes while keeping --text-muted for subdued icons
• derive search match backgrounds from each theme's link color instead of
  using fixed yellow overlays
• improve Solarized Dark body contrast and adjust links in Elegant, Sepia,
  and Solarized Dark to meet WCAG AA
• let imported custom-theme variables override the default Light tokens

Why

The previous search overlays became difficult to read on dark themes, while
--text-muted was shared by both decorative icons and small readable labels.
Solarized Dark body text also had insufficient APCA contrast, and three link
colors fell below WCAG AA.

Validation

• node scripts/check-theme-colors.mjs
• npm run build
• git diff --check origin/main...HEAD
• visual checks in Light and Solarized Dark for search matches, editor text,
  and file-panel secondary text

[orange2ai]

Custom themes currently support direct selectors as documented in themes/README.md, and may intentionally override only a subset of CSS variables. Changing the Light defaults from body, body.theme-light to body:not(.theme-custom), body.theme-light removes every fallback token when an imported theme adds theme-custom. A direct-selector-only or partial custom theme will then lose tokens such as --bg-color, --text-color, and --border-color.\n\nPlease preserve the default token baseline for custom themes while allowing imported CSS to override it, and add regression coverage for both a partial-token theme and a direct-selector-only theme. The standalone theme color check should also be exposed through a package script so it is part of the normal verification path.