Redesign flow trigger conditions with CRUD component

What does this MR do and why?

Aligns the flow trigger form with the CRUD panel used elsewhere in the product, such as protected branches and protected tags.

Conditions are now listed with a plain-language summary and added one at a time, as either a schedule or an event, rather than picked all at once from a multi-select with a configuration card stacked per selection. Naming follows, so a trigger no longer contains "triggers".

No changes to what a trigger saves: the payload is unchanged.

Two incidental fixes came out of building it. Event type 8 rendered as "Schedule", because the frontend's schedule type borrowed it as a placeholder id while the backend already assigns it to commit_to_default_branch, so those triggers now show their real name and a schedule carries no id until the backend defines one. Separately, a condition left open in the add or edit form was silently dropped on submit, and now blocks saving until it is finished or cancelled.

References

Mirrors the conditions builder prototyped in !248126

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. In a project where Duo features are enabled, go to Automate > Triggers and select New trigger.
2. Fill in the description and target, then use Add condition > On an event to add an event. Confirm that:
   • Events needing configuration (pipeline, merge request, work item) show their Run when field inside the same form, and the field reports its own error when left empty.
   • Events needing no configuration (mention, assign, assign reviewer) save straight away.
   • An event already in the list is no longer offered by the picker.
   • Rows summarize what was configured, for example Pipeline events: Passed, Failed.
3. Submit with an empty list and confirm the form blocks with Add a condition so this agent or flow knows when to run.
4. Leave an Add condition form open and submit, and confirm the form blocks with Finish or cancel the open condition before saving.
5. Edit an existing trigger and confirm its stored event types load as rows, that editing one preserves its configuration, and that switching an event type clears the previous configuration rather than leaving it behind.
6. Save and reload to confirm the payload round-trips unchanged.

To exercise the schedule branch, temporarily change FLOW_TRIGGER_TYPE_SCHEDULE.isAvailable to () => true in ee/app/assets/javascripts/ai/duo_agents_platform/constants.js. Adding, editing and removing work in the panel, but a schedule is omitted from the payload on submit, because the backend enum has no schedule member to store it under.

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.