Define InputGroup-compatible controls

## Problem

`InputGroup` is a composite input surface: it visually connects one compatible input control with prefix/suffix addons inside a shared border and focus ring. After #3502, `TextInput` and `NumberInput` correctly consume `InputGroupContext` so they can remove their own field chrome and compose the group label/description/status with their own input ARIA.

The docs and stories should make this compatibility boundary explicit. Some controls look input-like but do not make sense inside `InputGroup` because they are not single-line composite input surfaces or because they have their own group semantics.

## Current compatibility

Supported today:

- `TextInput`
- `NumberInput`
- `InputGroupText` addons

Not compatible by design:

- `TextArea` — multi-line field; shared inline border/addon layout does not fit the interaction or layout model.
- `Slider` — has track/thumb semantics, not inline text-entry semantics.
- `Switch` — boolean toggle control, not a decorated text-entry surface.
- `CheckboxInput` — boolean control with its own label/status layout.
- `RadioList` — already a grouped composite control with radiogroup semantics.

Potential follow-up candidates, if explicitly designed and implemented:

- `TimeInput`
- `DateInput`
- `Selector`
- `MultiSelector`
- `Typeahead`
- `Tokenizer`

These should not be documented as compatible until they explicitly consume `InputGroupContext`, suppress their own `Field` wrapper when grouped, apply grouped border/radius styling, and compose group + input ARIA with the shared helper.

## Proposed work

1. Document the compatibility boundary in `InputGroup` docs.
2. Add Storybook stories that show every supported compatible control.
3. Add support for additional compatible single-line controls in small PRs, each with tests and Storybook coverage.
4. Keep unsupported controls documented as unsupported so users do not place arbitrary form controls inside `InputGroup`.

## Acceptance criteria

- `InputGroup` docs explicitly list supported controls and non-compatible controls.
- Storybook shows compatible examples for all supported controls.
- Any newly compatible control:
- consumes `InputGroupContext`
- uses shared grouped border/radius styles
- avoids rendering duplicate `Field` chrome inside `InputGroup`
- composes group + input label/description/status via `getInputARIA`
- has regression tests for grouped accessible name and described-by wiring

Refs #3343