DataViews: use action.disabled state to disable actions (primary and secondary)

[oandregal]

Related #67790 (comment)

What?

This PR uses the existing disabled property in the Actions API to disable the action buttons.

How?

Pass the action.disabled property to the button that renders it.

Testing Instructions

• Go to the Pages page.
• Make one of the actions disabled. For example, add disabled: true to edit.
• Switch to every layout and verify that the edit action is disabled (both as primary and secondary).

List	Grid	Table

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

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

[youknowriad]

This looks good. But I'm curious why did we introduce the action.disabled API in the first place? I mean what are the use-cases?

[github-actions]

Flaky tests detected in 45a1d78.
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/12482690337
📝 Reported issues:

• [Flaky Test] Navigates the items list via UP/DOWN arrow keys #64334 in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js
• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[oandregal]

This looks good. But I'm curious why did we introduce the action.disabled API in the first place? I mean what are the use-cases?

Right, I don't know what use cases covers a boolean that needs to be resolved at registration time. Having a isDisabled function that mimics isEligible would be a more flexible API, imo. For example, it'd enable us to support things similar to the first use case here #68134 (disable when the page is the homepage).