fix: give a darkHue-only color its own hue var in both schemes

[tenphi]

Follow-up fixes that were left uncommitted when #84 (darkHue / darkSaturation) and #82 (extreme tone with a base) were merged. Re-applied on top of current main — the original changesets were already consumed by the version-packages PRs, so this ships its own patch changeset.

The bug

A color that authored only darkHue (no light hue) got the theme's --{name}-hue var as its var() reference in both schemes. The per-color --{color}-hue declaration was still emitted in the dark block — but nothing read it, so the dark hue was silently dropped.

theme.colors({ surface: { tone: 35, darkHue: 90 } });
theme.css({ format: 'oklch', splitHue: true, name: 'brand' });

Before, dark got --surface-hue: 90; next to a --surface-color that still interpolated var(--brand-hue).

A color that authors a hue in either scheme now gets its own hue custom property in both, tracking the theme hue (--surface-hue: var(--brand-hue)) in the scheme it did not author — so the shared reference stays valid and runtime re-skinning still works. Applies to css({ splitHue: true }) and the Tasty token map alike; darkHueDeclarations becomes buildHueDeclarations, returning both schemes so the two sides can't drift apart again.

Colors that author a light hue are unaffected — they already got their own var in both schemes.

Docs correction

docs/api.md claimed high-contrast variants were exempt from the extreme-tone light-shift replay because "their window is already the full range". They aren't exempt — they follow the same rule; the full-range window just means the replay usually reproduces the plain mapping, and only diverges when the base itself sits asymmetrically across schemes (a mode: 'fixed' or contrast-solved base). Added a test pinning that divergence, plus assertions locking the exact tone values docs/api.md cites.

No behavior change in the resolver

extremeDarkTone was already only called with isDark === true, where baseTone was the dark variant's tone — so dropping the redundant baseDarkTone parameter, moving the extreme branch inside the absolute/extreme arm, and folding the extreme's tone clamp into the solve literal are all cleanups. Verified: reverting the source fixes leaves only the new splitHue test failing.

Checks

pnpm test (353 passed), pnpm run typecheck, pnpm run lint, pnpm run format:check — all clean.

🤖 Generated with Claude Code

[github-actions]

📦 Snapshot release

Published 0.0.0-snapshot.13fe6d5.

pnpm add @tenphi/glaze@0.0.0-snapshot.13fe6d5