Keep external drop effect as copy

[HardyPotato]

🚀 Summary

Keeps external drag operations advertised as copy in the clipboard drag/drop plugin.

The dragging handler already detects external drags with !this._draggedRange and sets dataTransfer.dropEffect = 'copy'. In non-Gecko browsers, the next branch could immediately overwrite that value to move when effectAllowed was all or copyMove.

This change only runs the non-Gecko effectAllowed fallback for internal editor drags. External drags keep the explicit copy drop effect.

---

📌 Related issues

• Closes External drag/drop can force move dropEffect in Chromium #20161

---

💡 Additional information

Manually verified using the clipboard drag/drop manual test page in Chromium. External file drags over the editor no longer forced dropEffect = "move".

Automated regression coverage added in packages/ckeditor5-clipboard/tests/dragdrop.js.

Checked locally with:

npx pnpm@10.28.0 run test --files=clipboard/dragdrop

---

🧾 Checklists

Author checklist

• Is the changelog entry intentionally omitted?
• Is the change backward-compatible?
• Have you considered the impact on different editor setups and core interactions? (e.g., classic/inline/multi-root/many editors, typing, selection, paste, tables, lists, images, collaboration, pagination)
• Has the change been manually verified in the relevant setups?
• Does this change affect any of the above?
• Is performance impacted?
• Is accessibility affected?
• Have tests been added that fail without this change (against regression)?
• Have the API documentation, guides, feature digest, and related feature sections been updated where needed?
• Have metadata files (ckeditor5-metadata.json) been updated if needed?
• Are there any changes the team should be informed about (e.g. architectural, difficult to revert in future versions or having impact on other features)?
• Were these changes documented (in Logbook)?

Reviewer checklist

• PR description explains the changes and the chosen approach (especially when performance, API, or UX is affected).
• The changelog entry is clear, user‑ or integrator-facing, and it describes any breaking changes.
• All new external dependencies have been approved and mentioned in LICENSE.md (if any).
• All human-readable, translateable strings in this PR been introduced using t() (if any).
• I manually verified the change (e.g., in manual tests or documentation).
• The target branch is correct.

[HardyPotato]

This PR was recreated from current upstream master on a fresh branch after #20184 also failed to receive a CLA status context.

Current head: 0ecab54955f6f4db2eb0b245beaff82b79981a5e
Commit author/committer: Allan Greco <github@sl.anvli.cc>
GitHub commit signature: verified

The CLA checker page still renders no PR status/commit block for this PR: https://cla.ckeditor.com/check/ckeditor/ckeditor5/20185

The contributor has completed the CLA flow from the github@sl.anvli.cc alias. Could someone from CKSource please retrigger/reconcile the CLA check for this fresh PR?