UI: Define policy for exposing Base UI CSS variables and data attributes

Context

From discussion on #76438: Base UI components expose public APIs beyond React props — specifically CSS custom properties (e.g. --available-height, --anchor-width, --transform-origin on the Positioner) and data attributes (e.g. data-open, data-side, data-starting-style).

Decision

We agreed to use Base UI's CSS custom properties and data attributes directly — no aliasing or namespacing with a --wp-ui-* prefix. Gating them adds maintenance overhead with no practical benefit, especially since data attributes can't be gated at all.

However, these APIs must be documented, since they are part of the effective public API of each component.

What needs to be done

1. Per-component documentation

Each @wordpress/ui component that exposes Base UI CSS variables or data attributes should document them. This includes:

• CSS custom properties available on specific sub-components (e.g. --available-height, --anchor-width on Popover.Popup's positioner)
• Data attributes that can be used for styling (e.g. data-open, data-side, data-starting-style)

Open question: where and how should this documentation live?

• In the component's TypeScript types (JSDoc)?
• In Storybook stories / docs pages?
• In a dedicated section of the component's README?
• Some combination of the above?

2. Package-level documentation

Add a section to the @wordpress/ui package documentation explaining the overall policy:

• @wordpress/ui components are built on Base UI primitives
• Base UI exposes CSS custom properties and data attributes as part of its component API
• These are passed through directly (not aliased or namespaced)
• Consumers can rely on them for styling, but should be aware they originate from Base UI and may change if the upstream library changes
• Link to Base UI's documentation for each component as the authoritative reference

3. Audit existing components

Review all existing @wordpress/ui componen