feat(Accordion): add AccordionGroup, Text headers and find-in-page search

[Lisa18289]

Stacked accordions inherited their parent's gap and read as separate, bulky blocks; a Label header left the accordion out of the page outline; badges in the header broke out of the toggle; and collapsed content was invisible to find-in-page. Closes #1838.

AccordionGroup renders its accordions as one block with separators, so the parent's gap only applies around it. Single-expand is opt-in, and the controlled state uses React Aria's prop names. The group keeps its own expansion state instead of using DisclosureGroup, which ignores an item's defaultExpanded.

The Accordion builds on useDisclosure: collapsed panels are hidden="until-found" and expand on a find match, which drops Flow's Activity from the accordion. Heading stays a heading (now h3 by default, at its own font size), Text renders a plain toggle with a smaller chevron. Label renders a plain toggle as well. variant is deprecated as a whole: "outline" no longer draws a frame, so the prop has no effect left and warns when passed. The migration entry accordion-variant-deprecated removes it with a codemod and points to AccordionGroup for separators. Header and content text sit on the surrounding content's edge via a negative inline margin, and heading spacing follows section.spacing and the section's sub-heading spacing. Navigation moves onto the menu tokens with the same alignment, and the List's filter modal groups its accordions.

Collapsed content now always mounts, so find-in-page reaches it. Flow's Activity no longer defers it until expansion: effects and data loading inside a collapsed accordion run on page load. Every consumer still passing variant="outline" loses the frame.

Worth a look: the new accordion.* token values were tuned in review, not by UX; the default heading level moves from 4 to 3, which changes every accordion without an explicit level.

🤖 Generated with Claude Code

[github-actions]

🚀 Preview Deployment

Preview environments are ready:

Type	URL
docs	pr-3409.docs.review.flow-components.de
storybook	pr-3409.storybook.review.flow-components.de

Images:

• docs: ghcr.io/mittwald/flow/docs:pr-3409
• storybook: ghcr.io/mittwald/flow/storybook:pr-3409

[Jan-Eimertenbrink]

wenn Padding x und padding y beide auf size s gehen könnten wir einfach nur Padding haben. Unten text-padding und content-padding ist ja okay wenn diese noch mal spezieller sind.

[Jan-Eimertenbrink]

Frage sollten wir nicht lieber padding-text-y als token schreiben ich glaube so haben wir es doch auch immer beim rest gleiches gilt für content und header.