fix(ui): hide unused permalink field for Rewrite & Republish copies

[faisalahammad]

Context

• Issue Rewrite and Republish feature displays permalink field in editor, but this field is not used #437 reports that the block editor shows a permalink/URL row when editing a Rewrite & Republish copy. That URL belongs to the copy and is never used: on republish, Post_Republisher::republish_post_elements() always restores the original slug. Users worry the post moves to a new URL when they republish.
• We already tried to hide this row with removeEditorPanel( 'post-link' ) in js/src/duplicate-post-edit-script.js, but that is a stale identifier. Recent WordPress renders the row from the permalink_template and generated_slug fields in the REST edit response, and it only shows the row when a permalink template comes back. So the old call does nothing anymore.

Summary

This PR can be summarized in the following changelog entry:

• Fixes a bug where the block editor showed an unused permalink URL when editing a Rewrite & Republish copy.

Note: I cannot add labels from my fork account, so a maintainer needs to add the changelog: bugfix label.

Relevant technical choices:

• Instead of hiding editor UI, the two permalink fields are removed from the REST edit response for Rewrite & Republish copies only. Gutenberg hides the URL row by itself when no permalink template is returned, so status & visibility, publish date, authors, template and discussion all stay visible.
• The filters are registered on rest_api_init for all post types with show_in_rest, so custom post types are covered too.
• The copy's own slug in the database is left alone, and the removeEditorPanel( 'post-link' ) call in the JS stays as a harmless fallback for older editors. No JavaScript was changed.
• The classic editor already hides the slug UI for copies, so this brings the block editor in line with it.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Create a post and publish it.
• In All Posts, click Rewrite & Republish under that post.
• The copy opens in the block editor. Open the Settings sidebar and look at the Summary panel.
• Before this fix you see a permalink/URL row with a different slug than the original. After the fix, that row and its slug input are gone.
• Status & visibility, publish date, Authors, Template and Discussion should still be visible and work.
• Change something and click Rewrite & Republish to republish the post.
• The original post is updated at exactly the same URL.
• Open the original post in the editor: the permalink row is back and the slug can still be edited.
• Optional: allow Rewrite & Republish for a custom post type in the plugin settings and repeat the copy editor check there.

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 console check is here because two fields are dropped from the REST response, so any editor component that reads them should degrade quietly and not throw.
• The post type check covers custom post types with show_in_rest, because the filters are registered per post type.
• For editors: the change only targets the block editor for copies. The classic editor already hid the slug UI and should not change; Elementor is not touched.

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:

Impact check

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

• Only REST edit responses for posts marked as a Rewrite & Republish copy (_dp_is_rewrite_republish_copy) change. Normal posts keep their permalink fields, and New Draft duplicates are not affected.
• Other REST clients that request the edit context for a copy will no longer see the two permalink fields for that copy. This is the intended effect and nothing else changes in the response.

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.

Fixes #437