RemixIconButton duplicates its accessible name

[leoafarias]

Summary

RemixIconButton/FortalIconButton exposes the same accessible name on two semantics nodes.

Found while validating #80 at b16636b017f3c8832d8f27f316cc24c0ad92ce8a.

Evidence

RemixIconButton.build assigns the label twice:

• semanticLabel on the outer NakedButton;
• the same label on a nested Semantics/MergeSemantics.

Minimal reproduction:

testWidgets('icon button has one accessible name', (tester) async {
  await tester.pumpRemixApp(
    FortalIconButton(
      icon: Icons.refresh,
      semanticLabel: 'Refresh',
      onPressed: () {},
    ),
  );

  expect(find.bySemanticsLabel('Refresh'), findsOneWidget);
  // Actual: 2 matching semantics nodes.
});

A FortalButton(label: 'Save', semanticLabel: 'Save') under the same harness produces one match, so this is not a general NakedButton problem.

Expected

One focusable, actionable button node owns the accessible name, enabled/loading state, hint, and tap action.

Suggested direction

Make the outer NakedButton the single semantic owner. Merge loading/live-region information onto that contract without adding a second labelled descendant. If the inner surface needs semantics for another reason, exclude its duplicate name.

Acceptance criteria

• An enabled icon button exposes exactly one named button node with one tap action.
• Disabled and loading buttons retain one node with correct state and no unintended activation.
• semanticHint, excludeSemantics, focus, and long-press behavior remain covered.
• Default and explicit labels do not create labelled descendants.

Ownership

The duplicate is introduced by Remix composition after NakedButton; Naked UI does not need a change for this issue.

[leoafarias]

Resolved by #80 and included in merge commit 40704eb. The merged PR includes the implementation and verification for this issue. Closing as completed.