feat: implement style api for autosuggest component

[mxschll]

Description

Extends the autosuggest component with a style API for customization, allowing developers to override default component styles.

Related links, issue #, if available: n/a

How has this been tested?

• Added unit tests for style prop validation and CSS class application
• Screenshot tests passed without visual regressions

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 96.99%. Comparing base (c99509e) to head (b46554e).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4054   +/-   ##
=======================================
  Coverage   96.99%   96.99%           
=======================================
  Files         862      862           
  Lines       25226    25226           
  Branches     9111     9111           
=======================================
  Hits        24469    24469           
  Misses        710      710           
  Partials       47       47           

☔ View full report in Codecov by Sentry.
📢 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.

[pan-kot]

This creates more combinations than needed: 2x disabled, 2x readOnly, 2x invalid, and 2x style give 16 combinations, out of which 8 feature disabled=true and readOnly=true that are of little interest.

Besides, there are no permutations that show placeholder value or warning state.

I recommend declaring more atomic permutation groups, e.g.:

[
  { value: ['value'], disabled: [false, true], invalid: [false, true], warning: [false, true], style: [style] },
  { placeholder: ['Placeholder'], disabled: [false, true], invalid: [false, true], warning: [false, true], style: [style] },
  { value: ['value'], readOnly: [false, true], invalid: [false, true], warning: [false, true], style: [style] },
  { placeholder: ['Placeholder'], readOnly: [false, true], invalid: [false, true], warning: [false, true], style: [style] },
]

The same can be done twice if that is really necessary to cover multiple styles. Alternatively, we can be a little creative here and include a style selector component instead, also controlled with an url flag. Thus, opening a page with ?style=style1 will render one style, and using ?style=style2 will show an alternative style (provided there is actual value in having more than one).

[mxschll]

What do you think about this approach at /textarea/pseudo-selectors? That way we could interact with it in the screenshot tests (like hover, focus) more easily?

[pan-kot]

I think the current approach with a single style is ok for now. The highly dynamic approach is good for manual testing or integration tests, but not so much for permutations. There, we can introduce maybe a single control to select out of a few available styles, while keeping the rest of the states predefined so to ensure good coverage with min configuration.