fix: copy the sticky state when duplicating

[faisalahammad]

Context

Issue #371 reports that the sticky setting is lost when a post is duplicated with Rewrite & Republish in the Classic Editor. The same happens with Clone and New Draft. Sticky state is stored in the sticky_posts option, not in post fields or post meta, so both duplication paths skip it.

Summary

This PR can be summarized in the following changelog entry:

• Fixes a bug where the sticky setting was not copied when duplicating a post.

Relevant technical choices:

• Sticky state lives in the sticky_posts option, so it is copied explicitly with is_sticky() / stick_post() after the duplicate is inserted, in both the namespaced Post_Duplicator (Rewrite & Republish) and the legacy duplicate_post_create_duplicate() (Clone, New Draft, bulk actions).
• The copy is only stuck when the original has the post post type, since stick_post() does not validate the post type but the sticky UI in core only exists for posts. This keeps duplicated pages, attachments and custom post types untouched.
• Republishing deliberately does not touch sticky state. The original keeps its entry in sticky_posts, and when the Rewrite & Republish copy is deleted, core's _reset_front_page_settings_for_post() removes its ID from the option, so no stale IDs are left behind.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

1. Create or edit a published post and make it sticky (checkbox "Stick to the top of the blog" in the editor, or Quick Edit in the post list).
2. Open the post in the Classic Editor and click "Rewrite & Republish".
3. In the copy, look at the "Stick to the top of the blog" checkbox in the Publish box. Expected: it is checked.
4. Make a small change, click "Republish" and return to the posts list. Expected: the original post is still sticky.
5. Repeat step 2 with "Clone" and "New Draft". Expected: both copies are sticky.
6. Duplicate a page and a sticky-eligible custom post type if enabled. Expected: they duplicate as before, nothing becomes sticky.
7. Repeat step 2 in the block editor. Expected: behavior is unchanged from before this PR.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

The reported issue is Classic Editor specific, so both Classic and block editor flows were checked (steps 3 and 7). Sticky is a posts-only feature, so pages and enabled custom post types were verified not to become sticky (step 6).

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Same steps as the acceptance test above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• Post duplication in both the namespaced Post_Duplicator class and the legacy duplicate_post_create_duplicate() function. Everything that does not involve the post post type is unaffected because of the post type guard.

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities
• I have added unittests to verify the code works as intended

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label and noted the work hours.

Note: I cannot attach labels as an outside contributor, so this PR still needs the changelog: bugfix label.

Fixes #371