[Collapse]: Refactor Collapse to use the new CollapseButton primitive

[ly-tempel-bitweb]

Problem

PR #666 introduced CollapseButton, currently consumed only by AccordionItemHeader. The existing Collapse component has its own copy of the same chevron-toggle UI.

Solution

Collapse wraps the entire header (title + chevron) in one <button>, so clicking the title toggles. CollapseButton is itself a <button> — nesting them is invalid HTML. So a straight swap isn't possible without making one of these choices:

• A. Move the title out of the button — single code path, cleanest. Breaking: clicking the title no longer toggles.
• B. Hybrid — keep current behaviour when title is set; use CollapseButton only when title is absent. No breakage, two code paths.
• C. Angular-parity — drop title, controlsId, toggleLabel, BreakpointSupport, Print integration, titleRowProps, iconOnly, underline. Match Angular's minimal tedi-collapse API. Smallest component, aggressively breaking.

Recommended: A.

Stories simplification

While we're in there, the React Collapse stories should also be simplified to match the Angular structure — Angular's tedi-collapse stories are leaner (no per-state matrix duplication, fewer custom templates). The story file should mirror the Angular set: Default, plus a handful of focused variant stories.

DoD

• The component is developed using best practices, conventions, and modern frontend trends
• The component follows BEM naming conventions (if applicable)
• The component implementation matches the Figma design, including all defined states and interactions
• The component supports responsiveness and scales across breakpoints (if applicable)
• The component does not introduce runtime errors or warnings
• Linter passes
• Component has export if needed
• The component has unit tests with at least 80% code coverage
• CodeCov passes minimum coverage threshold
• The component has passed code review
• The component has passed Chromatic visual review
• Storybook stories are created:
  • Cover all Figma variations
  • Include edge cases, empty/error states
• Component’s API (props, slots, events) is documented
• ZeroHeight is updated with design/development guidelines
• External dependencies used in the component are documented in Confluence with rationale.
• Semantic commit format is used (for semantic-release)
• External libraries comply with validated open source licenses
• Component is versioned correctly and ready for release if required
• Update statuses page in Zeroheight

[ly-tempel-bitweb]

Discussed this with the team and we decided to go with option A.