feat: add reset to defaults to collection preferences

[ernst-dev]

Description

Adds an opt-in "Reset to defaults" affordance to CollectionPreferences, resolving AWSUI-61145. Customers can now restore a table's/cards' default preferences in a single action instead of undoing each change individually.

What changed

• New optional resetToDefaults config: { label?: string; preferences: CollectionPreferencesProps.Preferences }. When set, a link-style reset button is rendered in the modal footer (left-aligned), matching the placement requested by customers in the ticket. When it is not set, the footer is unchanged.
• New optional onReset callback (NonCancelableEventHandler<Preferences>) fired when the user activates the reset button. The detail contains the default preferences the modal's working state was restored to.
• Clicking reset restores the modal's working (temporary) state to resetToDefaults.preferences; the user still confirms via the existing confirm button for the change to take effect. The modal does not close on reset.
• i18n: the reset label is wired through the collection-preferences namespace as resetToDefaults.label (default English "Reset to defaults"), with a matching entry in messages-types.ts.
• findResetButton() added to the CollectionPreferences test-utils DOM wrapper.

Backward compatibility: fully opt-in. No behavior change unless resetToDefaults is provided; existing props/events are untouched.

Related links, issue #, if available: AWSUI-61145

How has this been tested?

• New unit tests in collection-preferences.test.tsx (7 cases): button not rendered when opt-out; rendered with label; onReset fired with default preferences; no throw when onReset omitted; confirm applies reset preferences; modal stays open on reset; i18n label override.
• Full collection-preferences unit suite green (113 tests across 9 files) — no regressions.
• Added a dev page (pages/collection-preferences/reset-to-defaults.page.tsx) with a live controlled example showing current preferences and last reset detail.
• quick-build (TypeScript), eslint, and stylelint all pass under Node v24.

Review checklist

The following items are to be evaluated by the author(s) and the reviewer(s).

Correctness

• Changes include appropriate documentation updates.
• Changes are backward-compatible if not indicated, see CONTRIBUTING.md.
• Changes do not include unsupported browser features, see CONTRIBUTING.md.
• Changes were manually tested for accessibility, see accessibility guidelines.

Security

• If the code handles URLs: all URLs are validated through the checkSafeUrl function.

Testing

• Changes are covered with new/existing unit tests?
• Changes are covered with new/existing integration tests?

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.61%. Comparing base (f97729a) to head (5eb33b2).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4806   +/-   ##
=======================================
  Coverage   97.61%   97.61%           
=======================================
  Files         952      952           
  Lines       30816    30825    +9     
  Branches    11318    11322    +4     
=======================================
+ Hits        30081    30090    +9     
  Misses        688      688           
  Partials       47       47           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.