feat(remix): add toggle group

[leoafarias]

Summary

• add a complete, data-driven RemixToggleGroup<T> component backed by NakedToggleGroup<T>
• add group/item specs and stylers, selected/focused/disabled state styling, generated APIs, and a Fortal segmented-control recipe
• add a Widgetbook use case with orientation, loop, enabled, variant, size, and selection controls
• add component documentation and navigation
• add test helpers and a full pointer, keyboard, focus, RTL, disabled, loop/clamp, layout, spec, and style matrix

Why

Remix had standalone toggles but no single-select segmented-control component. Toggle Group provides one Tab stop, focus-only arrow navigation, explicit Space/Enter activation, orientation-aware movement, Home/End, disabled-item skipping, optional looping, and RTL-aware horizontal navigation.

Dependency note

The publishable dependency remains naked_ui: ^1.0.0-beta.3. A temporary dependency override tracks naked_ui main at d414875, where the roving-focus Toggle Group was merged in naked_ui PR #68. The override can return to a hosted version after the next naked_ui release.

Verification

• fvm dart run melos run ci --no-select
• generation check passed with no diff
• DCM passed with fatal style and warning checks
• demo package: 15 tests passed
• Remix package: 1,829 tests passed
• git diff --check origin/main...HEAD

[tilucasoli]

Review: follow-established-patterns pass

The component is solid — no correctness bugs. The risky mechanics (group→item enabled cascade, roving keyboard focus, and excludeSemantics) are all correctly delegated to naked_ui beta.4, which I verified against the resolved package source. The inline comments are all about matching patterns already established by sibling components; #1 (mergeActiveVariants) and #2 (_withOrientation) are the most substantive.

One finding that couldn't be anchored inline (file not in this diff):

• Missing FortalToggleGroup smoke test in packages/remix/test/components/fortal_widget_test.dart. The shared group('Fortal widgets') block has a testWidgets('renders FortalX') case for every @MixWidget fortal wrapper (FortalAccordion … FortalToggle … FortalTabBar/Tab/TabView). fortal_toggle_group_styles.dart defines @MixWidget(name: 'FortalToggleGroup') but no renders FortalToggleGroup case was added — it's the only fortal wrapper with zero render coverage in the aggregator.

[tilucasoli]

Two sources of truth for flex direction. Direction is already baked into the container at line 108 (FlexBoxStyler(direction: orientation)), then _withOrientation re-patches it onto the already-resolved spec here via a deep container.spec.flex?.copyWith(...) chain that always wins — making the line-108 direction effectively dead. Sibling tabs passes orientation only to NakedTabs and lets the single style spec own visual direction; no post-resolution mutation.

Two costs:

• The deep copyWith breaks silently if FlexBoxSpec/FlexSpec reshape, and a future edit to line 108 has no effect.
• _withOrientation also runs on the raw styleSpec path, so a caller who supplies a vertical RemixToggleGroupSpec but leaves orientation at its .horizontal default gets it silently forced back to horizontal — defeating the "bypasses fluent resolution" contract documented at lines 89-90.

[tilucasoli]

Minor / shared-pattern note (not a regression): on this raw styleSpec branch the group's default item styling comes from an already-resolved spec.item, so its onSelected/onHovered/onDisabled visuals are flattened away — a caller supplying a raw group styleSpec gets a static-looking segmented control. This matches select/menu exactly (inherent to the raw-spec escape hatch), so nothing to fix here — flagging only so the limitation is documented.