Add configured theme palette overrides

[konojunya]

Background

Users need palette-only custom themes that can use any valid theme identifier, including intentional overrides of the built-in default, light, and dark names. Resolution must remain deterministic and must not turn default extends default into a cycle. This follows the language and host-resolution contract proposed in stack-sh/specification#12.

Implementation Approach

• Add and distribute a JSON Schema for up to 32 palette-only configured theme definitions.
• Resolve every extends value from the immutable built-in catalog, replace built-in names in place, and append new names in identifier order.
• Normalize hexadecimal colors, preserve user choices, and return structured transparency and contrast warnings without silently rewriting colors.
• Derive a stable effective revision from the base catalog revision and normalized definitions.
• Publish the additive contract as version 0.8.0 without changing the built-in palette values.

Testing Approach

• Validate the source catalog, provider-pack fixtures, and configured-theme fixture.
• Verify generated Cargo/npm catalog and schema parity.
• Exercise custom names, built-in overrides, self-named extends, invalid identifiers, invalid colors, empty palettes, definition limits, normalized revisions, and warnings.
• Run Node tests, TypeScript checking, Rust tests, clippy with warnings denied, rustdoc, Cargo package verification, and npm pack dry-run.

Review Perspectives / Points of Concern

• Confirm that only palette tokens are configurable and all non-palette rendering records remain inherited from built-ins.
• Confirm that configured names take precedence while extends always reads the pre-overlay built-in catalog.
• Confirm the effective revision algorithm is sufficiently explicit for downstream render metadata.
• Confirm the 0.8.0 release does not change the built-in default, light, or dark color choices.