Add CSS variable fallback strategy documentation.

[kotAPI]

Description

We should document Rad UI’s CSS variable strategy clearly, including whether fallback values are supported, when CSS custom properties are expected to exist, and what consumers can rely on when using Rad UI’s styled or tokenized layers.

This issue should not imply that the headless core library itself requires a universal CSS variable fallback system. Instead, the documentation should clarify the contract for any Rad UI-provided styled systems, themes, or token layers that depend on CSS custom properties.

Problem

Without a documented CSS variable strategy:

• consumers do not know whether missing CSS variables are supported
• it is unclear whether var(--token, fallback) patterns are part of the public contract
• teams may attempt partial token overrides without understanding what is required
• maintainers have no clear documented stance on required versus optional variables
• theme customization and debugging become harder than necessary

This creates ambiguity around how styling tokens are expected to be provided and overridden.

Intended Position

The documentation should make the following explicit:

• whether Rad UI-provided styled systems require a complete token set
• whether partial CSS variable definitions are supported
• whether fallback values are used intentionally and where
• which CSS variables are considered part of the supported public styling contract, if applicable
• whether missing variables are treated as unsupported configuration rather than something the library guarantees to recover from

Proposed Scope

Add documentation that explains:

1. CSS variable usage model

• where CSS variables are used in Rad UI-provided styling layers
• what consumers are expected to provide or inherit
• whether the token system assumes complete theme definitions

2. Fallback strategy

• whether fallback values are used in component styles or theme layers
• when fallback values are internal implementation details versus supported customization behavior
• whether consumers should rely on fallback behavior at all

3. Customization expectations

• how consumers should override tokens safely
• whether partial token overrides are supported
• how to reason about missing or undefined CSS variables

4. Headless versus styled boundaries

• that the headless core library does not depend on a visual token fallback contract in the same way a styled layer might
• that CSS variable guidance applies to Rad UI-provided styling systems, not to the behavioral core in the abstract

Suggested Documentation Content

A docs page or section could include:

• how Rad UI uses CSS custom properties
• required versus optional variables
• supported token override patterns
• whether fallback values are part of the public API contract
• guidance for consumers adopting Rad UI-provided styled systems

Acceptance Criteria

1. Docs clearly explain the CSS variable strategy for Rad UI-provided styled/tokenized layers.
2. Docs clarify whether fallback values are supported and where.
3. Docs explain whether consumers can rely on partial token definitions.
4. Docs distinguish between headless core behavior and styled-layer token requirements.
5. Related styling/theme documentation is updated for consistency.

Notes

This issue should focus on clarifying the public contract rather than implying that every CSS variable must always have an inline fallback. The main goal is to document what is required, what is supported, and what consumers should not assume when working with Rad UI’s tokenized styling layers.