feat: data-driven Color and Dimension type definitions (fixes #97)

[Emp1500]

Fixes #97.

spec-config.yaml claims to be the single source of truth for the DESIGN.md spec, but the Color and Dimension type definitions were hardcoded as
static prose in spec.mdx. This PR makes them fully data-driven, following the same pattern already used for typography_properties.

Changes

1. spec-config.yaml — new types: section with Color (description, formats, note) and Dimension (description only; units reuse the top-level units: array to avoid duplication).
2. spec-config.ts — TypeDefSchema, TypeDef interface, PRIMITIVE_TYPES export; types is a required field so a missing key is caught at load time.
   3)renderers.ts — typeDefinitions(config, typeName?) renderer; the optional typeName argument lets Color and Dimension be emitted at their original positions in the spec.
3. spec.mdx — hardcoded Color/Dimension prose replaced with {typeDefinitions('Color')} {typeDefinitions('Dimension')}, preserving the original order: Color → typography properties → Dimension
   5)docs/spec.md — regenerated; output is identical in content to before.

[Emp1500]

I wanted to give a bit of context on the approach here since the implementation has a few moving parts.

The core idea was to follow the exact same pattern that typography_properties already uses — data in the YAML, rendered dynamically by a function. So typeDefinitions() in renderers.ts works the same way typographyPropertyList() does.

One thing worth calling out: Dimension doesn't have a formats list in the YAML because its units are already defined in the top-level units: array. I debated whether to duplicate them inside types. Dimension to make the type self-contained, but decided against it if they lived in both places, someone could update one and silently leave the other stale. The top-level units: array is already the authoritative list (the linter reads from it), so having Dimension reference the same source felt more honest. That said, if you'd prefer the type definition to be self-contained and are okay with a small duplication, happy to go that route instead.

I also kept the original reading order from spec.mdx — Color appears before the typography properties list, and Dimension appears after it. That meant giving typeDefinitions() an optional typeName argument so the two types could be emitted at their original positions rather than grouping them together.