Build from scratch: open the trigger picker so the user is guided into the workflow

Depends on #4848

User story

As someone starting a workflow from scratch, I want to be asked what triggers my workflow, so that the first decision about how my workflow runs is one I make deliberately rather than one that is made for me.

Details

Choosing Build from scratch on the landing screen currently drops the user onto a canvas that already has a webhook trigger and an empty first step, with nothing selected and nothing open. The workflow's trigger — arguably the most consequential decision in it — has been picked on the user's behalf, silently, and there is no prompt to reconsider it.

Webhook is a reasonable default, but it is only right some of the time. Someone building a scheduled report or a Kafka consumer starts by undoing a choice they were never asked about, and nothing on screen suggests that changing it is expected or easy. Users who don't know the trigger is changeable will simply build the wrong thing.

This was the intended behaviour for the epic. #4848 specifies that Build from scratch creates "a workflow with a webhook and job with trigger inspector component visible", and #4895 asked that the path invite the user to actively pick a trigger type rather than silently landing on a pre-picked webhook. It was built during #4918 and then dropped before merge due to complexity and time constraints.

Worth noting the "What triggers this workflow?" view already exists in the trigger inspector and is reachable today by selecting the trigger and choosing to change its type. This is about reaching it automatically at the right moment, not building it.

Release notes

Building a workflow from scratch now asks what should trigger it, instead of defaulting silently to a webhook.

User acceptance criteria

• Choosing Build from scratch lands the user on the canvas with the same workflow as it is currently but with the "What triggers this workflow?" view already open.
• Every implemented trigger type is offered, and picking one applies it to the new workflow.
• The user can dismiss the picker and keep the default without being blocked — this is a prompt, not a gate.
• The workflow is still created at the moment the card is clicked; opening the picker does not delay or condition that.
• The landing card copy is updated to describe the new behaviour. It currently reads "Start with a webhook trigger and an empty first step", which stops being true.

Start at the Build from scratch landing card and trace how it creates the canvas workflow, then read the existing trigger inspector and its "What triggers this workflow?" view. Done means that view opens automatically without delaying workflow creation, all implemented trigger types apply correctly, dismissal preserves the default, and the landing card copy reflects the new behavior.