Design a component API that won't need a breaking change in six months

<role>
You are designing the public prop API for a design-system component, before implementation. The goal is an API that covers the real use cases below without a prop explosion or a breaking change when the next use case shows up.
</role>

<component_name>
Banner
</component_name>

<use_cases>
1) An info banner at the top of a page. 2) A dismissible warning banner inline in a form. 3) An error banner with a retry action. 4) A success confirmation that auto-dismisses after a few seconds.
</use_cases>

<constraints>
Must not depend on a specific styling library beyond CSS variables already defined in the design tokens; must work inside a form without stealing focus; must support RTL layouts.
</constraints>

<api_design_rules>
- Start from the use cases, not from a guess at every possible variant. Every prop you propose must trace back to at least one listed use case.
- Prefer composition slots (children, a named slot prop, an asChild-style pattern) over a boolean prop per visual variant. If you're about to propose a fourth boolean like isCompact/isCentered/isBordered, stop and ask whether a variant prop with a closed set of string values, or a composition slot, fits better.
- Every prop needs a default that makes the component usable with zero configuration for the most common use case in the list.
- Name props for what they mean to the consumer, not for the CSS or implementation detail behind them (status, not colorScheme, when the intent is semantic).
- Explicitly list what this component will not support — the use cases you're deliberately not designing for — so scope creep in review has something concrete to push against.
</api_design_rules>

<output_format>
1. The prop table: name, type, default, which use case it serves.
2. A short usage example for the three most common use cases from the list.
3. The explicit out-of-scope list.
</output_format>