Composite: fix legacy implementation passing store prop

[ciampo]

What?

Extracted from #65720

Fix internal implementation of Composite to make it work better with legacy usages

Why?

This fixes a big that could cause Composite to stop working as expected when used via its legacy, unstable exports

How?

By explicitly grabbing the store prop and explicitly prioritizing it against the store read from internal context.

This is necessary because of how the legacy implementation of Composite works, which allows folks to pass a state prop to the old version of the component, which we needed to "translate" to passing a store prop in our legacy compat layer.

Testing Instructions

• All tests should pass
• The legacy Storybook examples of Composite should continue to work
• Make a change in Composite.Item that relies on the store logic (like the one applied in Composite: make items tabbable if active element gets removed #65720). On trunk, the change has a chance to break the CompositeItem legacy component, because it's not using the right store. This PR makes sure that, if the legacy implementation is passing a store via props, that store will be used instead.

[tyxla]

Tests well and code LGTM 👍 🚀 Thanks!

Just left a minor suggestion I made across all components about simplifying the code a bit.

[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: ciampo <[email protected]>
Co-authored-by: tyxla <[email protected]>

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

[ciampo]

Hey @tyxla , I applied your suggestion , improved comments, and also applied the same fix to the top-level Composite component, which I had initially skipped.

[github-actions]

Flaky tests detected in 41ab175.
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/11144041957
📝 Reported issues:

• [Flaky Test] The navigation text color should apply to all navigation links including submenu and overlay text #64584 in /test/e2e/specs/editor/blocks/navigation-colors.spec.js

[ciampo]

I tested on my machine and feel confident about the latest set of changes. Will merge once CI checks pass

[tyxla]

Yep, I can confirm the fix works as expected 👍

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch.

PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.

# Checkout the wp/6.7 branch instead of trunk.
git checkout wp/6.7
# Create a new branch for your PR.
git checkout -b my-branch
# Cherry-pick the commit.
git cherry-pick 695600a5c4ab8b5f93ed896ed3b426e247107c57
# Check which files have conflicts.
git status
# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue
# Push the branch to the repository
git push origin my-branch
# Create a PR and set the base to the wp/6.7 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.