Accept merged merge request filter action for Developer flow

What does this MR do and why?

First of three stacked MRs adding a merged merge request trigger for the Developer foundational flow, so a flow run can start after a merge request lands. This paves the way for further use cases, such as running a memory distillation session post-merge.

This MR is the substrate and is inert on its own:

• merged becomes a valid merge_request filter action, so a trigger with that action can be persisted.
• The Developer flow gains a goal template for the merged event.

Nothing dispatches the event yet — that arrives in MR 2.

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

Guarding the action

Developer.handler_for regains an optional params argument so the merge_request branch can dispatch on the action, and raises for anything other than merged.

This matters: developer/v1 declares no supported_events, so supported_events_match_foundational_flow returns early and any event type validates for it. ALLOWED_FILTER_ACTIONS already permits approved, and ExecuteMergeRequestApprovedWorkflowTriggersWorker is no longer feature gated. Without the guard, an approval would resolve to the merged template and tell the agent the merge request had been merged.

Stack

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

How to set up and validate locally

bundle exec rspec ee/spec/models/ai/flow_trigger_spec.rb \
  ee/spec/models/ai/catalog/goal_templates/developer_spec.rb

MR acceptance checklist

• Tested in the local environment (135 examples, 0 failures)
• No user-facing change, so no changelog entry