Proposal: Support OKLab and OKLCH color spaces in WinUI 3 (XAML + APIs)

### Title

Support OKLab and OKLCH color spaces in WinUI 3 (XAML + APIs)

### Summary

### Proposed scope

1. **XAML color parsing support**
- Add support for:
- `oklab(L a b)`
- `oklab(L a b / alpha)`
- `oklch(L C h)`
- `oklch(L C h / alpha)`
- Allow these anywhere color values are currently accepted (for example `Color`, `SolidColorBrush`).

2. **Public API surface for conversion**
- Provide framework conversion helpers for:
- OKLab/OKLCH ↔ linear sRGB
- linear sRGB ↔ encoded sRGB
- Ensure deterministic behavior with documented clamping and gamut handling.

3. **Perceptual interpolation options**
- Add opt-in interpolation modes for brushes/animations using OKLab/OKLCH.
- Preserve current RGB interpolation defaults for backward compatibility.

4. **Validation and diagnostics**
- Return clear parser/runtime diagnostics for invalid ranges, NaN/Infinity, hue normalization, and out-of-gamut results.
- Document channel ranges and normalization rules.

5. **Compatibility and performance**
- Keep existing hex/RGB/HSL/scRGB behavior unchanged.
- Ensure implementation is Native AOT-friendly and efficient for runtime theming/animation scenarios.

### Why this matters

OKLCH is not just alternate syntax for hex/RGB. It is a perceptual color model that enables:
- more uniform lightness steps,
- better gradient quality,
- more predictable palette generation,
- and easier cross-platform design-token parity with modern web workflows.

### Rationale

Modern UI systems need perceptually uniform color handling for predictable theming, accessible contrast tuning, and high quality gradients. Current WinUI color input paths are primarily sRGB based (hex/ARGB/scRGB/named colors), which makes many common operations non-uniform from a human perception perspective.

OKLab and OKLCH provide a practical, modern color model that improves real-world authoring outcomes:

- consistent visual lightness steps
- more stable hue/chroma adjustments
- better gradient interpolation behavior
- easier palette generation for light/dark themes
- improved ergonomics for design-token pipelines shared with modern web stacks
- As design systems increasingly standardize on OKLCH for token authoring, first-class support in WinUI would reduce conversion glue code, improve parity with modern CSS capabilities, and lower risk of color quality regressions during cross-platform token translation.

### Scope

| Capability | Priority |
| :---------- | :------- |
| Parse `oklab()` and `oklch()` color functions (including optional alpha) in WinUI 3 XAML color value locations. | Must |
| Provide public WinUI APIs for deterministic conversion between OKLab/OKLCH and sRGB (including linear sRGB steps). | Must |
| Preserve backward compatibility: existing hex/RGB/HSL/scRGB/named color behavior remains unchanged. | Must |
| Support opt-in perceptual interpolation for gradients/animations using OKLab or OKLCH, while keeping current interpolation as default. | Should |
| Define and document validation behavior for channel ranges, hue normalization, NaN/Infinity, and out-of-gamut handling. | Should |
| Provide guidance and examples for design-token workflows that author in OKLCH and render in WinUI brushes. | Could |
| Automatically switch all existing WinUI color interpolation and parsing behavior to OKLCH by default. | Won't |

### Important Notes

_No response_

### Open Questions

_No response_

The proposal names no files, tests, or entry points. Start by locating WinUI 3 color parsing, public color APIs, and interpolation code, then clarify the design and scope before implementation; done would require the specified parsing, conversions, diagnostics, compatibility, and performance behavior.

Written by the indexing model from the issue text.