Backport of "Fix any_merge_request policy violations stuck in running on fork MRs"

What does this MR do and why?

Backport of !249921 (merged) ("Fix any_merge_request policy violations stuck in running on fork MRs") into 19-4-stable-ee.

• Security::ScanResultPolicyViolation rows for any_merge_request approval policy rules get stuck at status: running on merge requests opened from a fork, especially personal-namespace forks.
• While stuck, detailed_merge_status stays security_policy_violations, so the merge widget spins forever and the MR can't be merged. Since 18.4 removed the policy_mergability_check flag, this is a hard gate with no automatic recovery, only a manual close/reopen or a new push.
• Fix gates policy work on the merge request's target project instead of the fork/pipeline project, and reorders violation creation in EE::MergeRequests::CreateService#after_create so violations exist before NewMergeRequestWorker is enqueued.
• Backend and spec changes only. No migrations, no feature flag, no UI change, no data migration for merge requests already stuck.
• Requested via a customer escalation and request-for-help work item https://gitlab.com/gitlab-com/request-for-help/-/work_items/5212. The customer has been blocked since the fix originally targeted 19.3. Backport requested at !249921 (comment 3843165969).

Original MR merged to master on 2026-09-22 (milestone 19.5), squash commit ebc1a753775a709148c2b2244bd2a67b1975cc3c, cherry-picked here with -x.

Backport notes

• Cherry-pick was clean except one spec conflict in ee/spec/workers/security/scan_result_policies/unblock_pending_merge_request_violations_worker_spec.rb, caused only by an unrelated master-only change to the RSpec.describe line.
• Resolved by keeping the 19.4 RSpec.describe line and applying only the patch's own additions. Verified with git range-diff that the applied patch is otherwise byte-identical to master.

Screenshots or screen recordings

Before	After
N/A - backend and spec changes only, no UI change	N/A

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes). (Original MR is currently workflow::canary; not yet on production, must be confirmed before merging this backport.)
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the E2E Omnibus GitLab EE pipeline (triggered by thee2e:test-on-omnibus-ee job) has succeeded. If it has failed (or shows warnings), investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request. (Branch was pushed with ci.skip; a pipeline must be started manually.)

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.