Posts: Prevent private posts from becoming sticky in Quick and Bulk Edit

[himanshupathak95]

Trac ticket: https://core.trac.wordpress.org/ticket/39946

Private posts are only visible to authorized users and do not appear in public front page queries (is_home()). Consequently, private posts cannot and should not be made sticky.

While single post editing (edit_post()) correctly enforces this constraint by unsticking private posts, wp-admin/edit.php previously allowed private posts to become sticky via Bulk Edit both in the UI and in the bulk_edit_posts() backend handler. Quick Edit UI also left the sticky checkbox active when Private status was checked.

This PR resolves ticket #39946 by:

1. Updating bulk_edit_posts() in src/wp-admin/includes/post.php to automatically call unstick_post() whenever a post's status is or becomes private.
2. Updating src/js/_enqueues/admin/inline-edit-post.js to disable and reset the "Sticky" dropdown when "Private" status is selected in Bulk Edit.
3. Updating inline-edit-post.js to delegate event handling on table.widefat so Quick Edit rows properly uncheck and disable the "Sticky" checkbox when "Private" is selected.
4. Adding PHPUnit test coverage in tests/phpunit/tests/admin/includesPost.php.

Testing Instructions

1. Navigate to Posts > All Posts (wp-admin/edit.php).
2. Open Quick Edit on any post and check "Private". Verify that "Make this post sticky" becomes disabled and unchecked immediately.
3. Select multiple posts and open Bulk Edit. Change Status to "Private". Verify that the "Sticky" select dropdown resets to "— No Change —" and is disabled.
4. Run the PHPUnit test suite: npm run test:php -- --filter=Tests_Admin_IncludesPost.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props abcd95.

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