Consider making triggers distinct from steps in the runtime

At the moment, a trigger in the runtime is just a step with no expression.

It might be cleaner to represent triggers as a different array in the workflow:

{
  steps: {},
  triggers: { webhook: {}  }

A trigger would still have a next, so it is a kind of step really.

Workflows would have a rule like "execute from the first trigger" if a start isn't defined. That removes the workflow.start key, which is designed to set the default/intended start node. But workflows should start from a trigger- so by default you;d just start from a trigger. And if you want you can pass another trigger id.

This doens't really materially matter. But it might be a neater way to handle triggers internally, and keeps the workflow structure closer to the official project spec.

Start by reading the runtime's workflow and trigger handling, then compare the current structure with the official project spec. Determine how workflow starts and trigger IDs are represented, including the existing next relationship. Done means the design and implementation consistently distinguish triggers from steps without breaking workflow execution.