Trigger Developer flow when a merge request is merged

What does this MR do and why?

Second of three stacked MRs. Subscribes a new worker to MergeRequests::MergedEvent so a project that configures a merged merge request trigger gets a Developer flow run once the merge request lands.

Targets !249081 (merged) — depends on that MR for the merged filter action and the Developer goal template. Review that one first.

Why a resolve_current_user hook

MergeRequests::MergedEvent is a plain Gitlab::EventStore::Event, not a CloudEvent, so it carries no acting user — unlike every other worker using Ai::CloudEventsFlowTriggerWorker. Rather than publish a new CloudEvent (larger change, touches PostMergeService), the shared concern gains a resolve_current_user hook defaulting to the previous cloud_event.current_user behaviour. The merged worker overrides it to attribute the run to whoever merged.

close: gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#2519 (closed)

Feature flag

merge_request_merged_flow_trigger, default off, rollout issue #608484

The project is the actor, not the user, because the worker only has the merge request and its target project at gate time. Gating the UI on the current user while gating the worker on the project would let someone configure a merged trigger that never fires.

The flag ships in this MR rather than a standalone one because scripts/feature_flags/used-feature-flags fails on definitions with no detected usage, including on MR branches.

Stack

1. !249081 (merged) — accept the merged filter action + goal template
2. This MR — worker + feature flag
3. New Trigger UI (targets this branch)

How to set up and validate locally

bundle exec rspec \
  ee/spec/workers/ai/catalog/flows/execute_merge_request_merged_workflow_triggers_worker_spec.rb \
  ee/spec/lib/ee/gitlab/event_store_spec.rb

MR acceptance checklist

• Tested in the local environment (28 examples, 0 failures)
• Behind a default-off feature flag, so no changelog entry