Add authorization check on destination post during content import

[miyanialkesh7]

Summary

• The content-import filter already verified the requesting user could read the source post and validated the nonce, but never checked whether they were allowed to edit the destination post before writing imported content into it.
• Adds an explicit current_user_can( 'edit_post', $dest_post_id ) check in ContentImporter.php alongside the existing checks.

Scope note

Per review feedback on this PR, I've narrowed it down to just this authorization fix. The other changes that were previously bundled in here (ABSPATH guards, i18n fixes, PHPCS/Plugin Check suppressions) have been split out:

• ABSPATH guard additions have been dropped entirely — every file they were added to is a pure class/interface definition with no top-level output, so per WordPress/WordPress-Coding-Standards#1850 the check doesn't add real protection there.
• i18n fixes are now in a separate PR.
• PHPCS/Plugin Check cleanup is now in a separate PR.

Test plan

• Verify content import still succeeds for a user with edit_post capability on the destination post
• Verify content import is now blocked for a user without edit_post capability on the destination post

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[lloc]

Hello @miyanialkesh7, thanks for helping. Please do smaller PRs by grouping them so I can review them more easily. Thanks!

[miyanialkesh7]

Hey @lloc,

There is a checkbox available with every change. So, you can take your time to review the file by file, and if everything is good, then you can easily push those changes to the main/master branch.

Please refer to the screenshot below

---

[lloc]

How GitHub works is clear to me. ;-) What I want is different, though.

Every PR should have a precise scope. Yours seems to have at least 3, which is problematic whenever I have to revert changes for some reason.

Also, for the ABSPATH check, please have a look here for reference:

WordPress/WordPress-Coding-Standards#1850

A quote from a comment by Juliette:

Actually, the defined() check is essentially a nonsense-check unless the file gives direct output.

[miyanialkesh7]

Hi @lloc, thanks for the feedback — I've made both changes:

• Scope: split this PR into three focused ones. This PR (Add authorization check on destination post during content import #668) now contains only the current_user_can() authorization check on the destination post during content import. The i18n fixes moved to Fix i18n gaps in WP-CLI messages and the Quick Create button title #669, and the PHPCS/Plugin Check cleanup moved to Suppress verified false-positive PHPCS/Plugin Check warnings, remove redundant textdomain load #670.
• ABSPATH check: dropped it entirely rather than extending it further. You're right per the linked thread (Check for ABSPATH exit WordPress/WordPress-Coding-Standards#1850) — every file I'd added the guard to is a pure class/interface definition with no top-level output, so the check wasn't adding real protection there.

This PR should now be a small, single-purpose diff. Let me know if there's anything else you'd like adjusted.