UI: Remove redundant renderElement utility

[aduth]

What?

Updates @wordpress/ui package to remove its internal renderElement utility, and update usage to use equivalent Base UI utilities available since #74190.

Why?

• Consistency across components
• Reduced maintenance burden, deferring to library implementation
• Less error-prone, particularly around managing props merging

Testing Instructions

Verify tests pass, as both affected components have test coverage verifying props merging (added for Stack as part of the changes here):

npm run test:unit packages/ui

Verify Storybook stories for Box and Stack:

1. npm run storybook:dev
2. Go to http://localhost:50240/?path=/docs/design-system-components-box--docs
3. Observe stylized Box
4. Go to http://localhost:50240/?path=/docs/design-system-components-stack--docs
5. Observe stylized Stack

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aduth <[email protected]>
Co-authored-by: mirka <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Flaky tests detected in 09a425d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20604597708
📝 Reported issues:

• [Flaky Test] can be inserted after refresh #55509 in /test/e2e/specs/editor/various/patterns.spec.js

[mirka]

Nice cleanup 👍

[mirka]

I feel weird about testing the class merging like this. It's tied to an implementation detail, and is somewhat overtesting what I think we can trust the Base UI utility to handle.

Also I think it's actually hard to forward consumer-passed className/style props in a way that overwrites the respective props set by us, without triggering a TS error. So in that sense, it might be sufficient to check for prop forwarding, and not worry about the merging.

[aduth]

Yeah, originally I didn't have this and only added it later in 09a425d . I agree that we should be able to trust the utility to handle this, but there's also the potential for error in whether we're using it and whether we're using it correctly (which, for the record, we were not using it correctly prior to 09a425d, which fixed a subtle bug with duplicate class names). I also agree that this is very "open box" testing in mocking the exports of the dependency. I don't feel particularly strongly, so maybe it's fine to remove.