Populate trigger_event_type from the two triggered service paths

What does this MR do and why?

One Ai::FlowTrigger can carry several event_types, so trigger_flow_trigger_id records which trigger fired but not which configured event fired it. This MR populates the trigger_event_type column (shipped in !252533 (merged)) to close that gap for the AI Audit Event Report.

The value is written exactly where trigger_flow_trigger_id is written, gated on the same autonomous_trigger? predicate, at both sites in Ai::FlowTriggers::RunService:

1. #trigger_metadata_params — the catalog path, threaded through Ai::Catalog::Flows::ExecuteService to Ai::Catalog::ExecuteWorkflowService.
2. #create_workflow — the workload path.

resolved_trigger_event_type records the event only when the trigger is configured for it (checked against flow_trigger.event_types). Anything else leaves the column NULL and the run proceeds: this is a reporting field and must not take down a flow. That also covers callers sending values outside the enum, such as api_execution and sidekiq_worker, which would otherwise raise ArgumentError.

Like the sibling trigger columns, trigger_event_type travels through params rather than a dedicated argument on Ai::DuoWorkflows::CreateWorkflowService. It is undeclared in the REST workflow_params block and absent from the GraphQL create mutation, so clients cannot set it, and attr_readonly pins it at creation.

References

• Resolves https://gitlab.com/gitlab-org/gitlab/-/work_items/625044
• Parent: https://gitlab.com/gitlab-org/gitlab/-/work_items/606320
• Column, enum and ClickHouse replication: !252533 (merged)
• Scheduled trigger execution (shaped this work): !250838 (merged)

Screenshots or screen recordings

Not applicable: backend-only change, no UI.

How to set up and validate locally

Automated coverage:

• ee/spec/services/ai/flow_triggers/run_service_spec.rb — both write sites, the disabled autonomous_service_account_execution flag, and an event the trigger is not configured for.
• ee/spec/services/ai/catalog/execute_workflow_service_spec.rb — the value is forwarded through workflow params; non-enum event_type values stay NULL instead of raising.
• ee/spec/services/ai/catalog/flows/execute_service_spec.rb — the middle hop forwards the value.
• ee/spec/services/ai/duo_workflows/create_workflow_service_spec.rb — a trigger_event_type in params is persisted; params without it leave the column NULL.
• ee/spec/models/ai/duo_workflows/workflow_spec.rb — the event-type/trigger-id coupling convention.

Manual check in a Rails console with autonomous_service_account_execution and ai_flow_schedules enabled: fire an autonomous run via Ai::FlowTriggers::RunService (for example trigger_source: :scheduled on a trigger configured for scheduled), then Ai::DuoWorkflows::Workflow.last.trigger_event_type returns "scheduled" while sessions started without a trigger keep NULL.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.