Actions API: Register the homepage and posts page actions as entity actions - #84646

Part of #83537.

Fixes #76668.

Right now "Set as homepage" and "Set as posts page" are not entity actions. usePostActions() creates them with hooks that read the site settings and adds them to the actions the server returns, so wp_unregister_entity_actions( 'postType', 'page', array( 'set-as-homepage' ) ) doesn't remove them. They are hooks because their eligibility depends on the data of the stores (the homepage, the posts page and the front page template), while isEligible only receives the item.

This PR follows Approach C of #76668:

• Makes isEligible receive { registry } as its second argument, as callback already does.
• Makes DataViews evaluate isEligible in useSelect in the item actions, the list and activity layouts, the bulk actions and the picker footer, so the eligibility is evaluated again when the data it reads through the registry changes. The table and grid layouts also pass the registry to the check that decides if a row can be selected.
• Does the same in PostActions, the actions menu of the editor inspector.
• Moves set-as-homepage and set-as-posts-page to a new page collection of @wordpress/core-actions as plain actions, with their label and modal options in action.php and their isEligible and modal in action.tsx. Their isEligible keeps the checks the hooks did: the page is published, it isn't the homepage or the posts page already, and the theme has no front-page template.
• Registers them on the server for pages when the user has manage_options, the capability behind canUser( 'update', { kind: 'root', name: 'site' } ), and removes them from usePostActions(). They are registered after the other core actions, so the core actions keep the order they have on trunk.

Some notes:

• Only the actions that read the stores add work when the stores change, because useSelect only subscribes to the stores its callback reads. On wp-env, with 20 pages in the pages list, I dispatched 500 changes to the core store that no action reads (median of 7 runs): a change took 186 µs on trunk, 369 µs with this PR, and 183 µs with this PR and the two homepage actions unregistered. So the extra cost, about 9 µs per row, comes from the two actions reading the site settings and the templates, and the actions that only check the item cost the same as before. Loading the pages list until the action menus show took about 1.47 s in both.
• I considered passing the data the actions need with the items, but the homepage and the posts page are site settings, not data of each page. DataViews already passes the registry to callback, so I opted for passing it to isEligible too, which keeps both functions symmetric. The actions read the stores through that registry, not the global select(), which was the concern in Data Views: Add action for pages to set site homepage #65426.
• isEligible implementations that only take the item keep working. Code that calls isEligible outside DataViews should pass the registry, as it does for callback.
• The server only registers the two actions for the users who can manage the site settings, so the client no longer checks canUser( 'update', { kind: 'root', name: 'site' } ) before showing them.
• A plugin action registered for pages now comes after the two actions, because the core actions, these two included, are registered first. On trunk, usePostActions() adds them after every action the server returns.
• The strings of the modals and the notices of the two actions are now in a script module, so, like the other core actions, they are not translated until Script Modules: Fix missing translations of script modules #84651 lands. Their labels come from PHP and are translated.

Testing Instructions

1. Start wp-env with a block theme that has no front-page template (e.g. Twenty Twenty-Four), and create two published pages, "Page A" and "Page B".

2. Go to http://localhost:8888/wp-admin/site-editor.php?p=%2Fpage, open the actions of "Page A", and verify "Set as homepage…" and "Set as posts page…" show after the other actions, as on trunk.

3. Set "Page A" as the homepage. Without reloading, open its actions again and verify neither action shows, while "Page B" still has both.

4. Open "Page B" in the post editor, set it as the posts page from the actions menu of the inspector, and verify that, without reloading, the menu no longer shows either action.

5. Add this mu-plugin, reload the pages list, and verify the actions of "Sample Page" no longer show "Set as homepage…" and still show "Set as posts page…". On trunk, "Set as homepage…" stays.

   <?php
   add_action( 'wp_entity_actions_api_init', function () {
   	wp_unregister_entity_actions( 'postType', 'page', array( 'set-as-homepage' ) );
   } );
   

6. Log in as an editor and verify neither action shows in the pages list or in the inspector.

7. Enable the "Extensible Site Editor" experiment in Gutenberg > Experiments, and repeat steps 2, 3 and 5 with two new pages in http://localhost:8888/wp-admin/admin.php?page=site-editor-v2&p=%2Ftypes%2Fpage.

AI usage disclosure: fix and description drafted with AI assistance and reviewed by me.