Select: add an options-driven convenience API for the single-select case

Summary

Select only ships a fully-compound API (Select + Select.Trigger / Select.Value / Select.Content / Select.Group / Select.Label / Select.Item) plus a multiple union. The overwhelmingly common case is a single-select driven by a list of options — "here are the choices, here's the value, tell me when it changes." Every such call site has to hand-assemble the compound tree, which is a lot of boilerplate for the 90% case.

What every consumer ends up writing

To render one single-select, a consumer writes the trigger, the value (with placeholder + selected-label logic), the content, and maps options to items — then repeats it everywhere. We wrap it once into an options-driven component so call sites can say what to choose instead of how to render the menu:

<Select
  value={value}
  onValueChange={onChange}
  placeholder="Pick one"
  options={[
    { value: 'a', label: 'Apple', leadingIcon: <AppleIcon /> },
    { value: 'b', label: 'Banana' },
  ]}
/>

...plus a groups variant for headings, and searchable for the in-dropdown filter. It's a thin wrapper, but it's one that essentially every Apsara consumer needs and rebuilds independently.

Request

Add an options-driven convenience API for the single-select case, either as props on Select or as a small dedicated component. Ideally it accepts:

• options (flat) or groups (with headings)
• per-option label, value, disabled, optional leadingIcon
• placeholder, value / onValueChange
• searchable (wires the existing autocomplete/search-in-content)

The compound API stays for advanced layouts; this is purely additive sugar for the common path. It would also give the single-select case a cleaner type than the current multiple discriminated union, which a single-select consumer has to narrow around.

Willing to contribute

Happy to open a PR if you'd like this in-library rather than re-wrapped per consumer.

Start by reading the existing Select compound API and the autocomplete/search-in-content entry point. Trace how single-select values, labels, disabled options, and groups are currently represented before choosing the wrapper's location and types. Done means the additive API supports flat options, grouped options, controlled value changes, placeholders, leading icons, and searchable menus without changing the compound API.