feat(execution-core): require start node

[dawidaksamski]

What

The runner inferred entrypoints by counting incoming edges, so any in-degree-0 node was
a root. Delete a node's only edge and it silently became a second entrypoint: it ran in
wave 1 with no upstream context, and its output still flowed downstream. In the
support-triage template that produced a successful run containing a fabricated reply.

The SDK already knows which node is the start, but the kind never reached the backend —
the snapshot schema stripped it.

Now: the react-flow node kind survives validation, mapNode lifts it to a runner-level
role: 'start', and a new resolve-start-node.ts resolves the entrypoint before the
first wave. The runner seeds ready with that node instead of every in-degree-0 node.

Exactly one start, no fallback

The compatibility ramp originally planned here (fall back to in-degree-0 roots when
nothing is declared) was dropped on request. Deliberate consequences:

• A definition with no role: 'start' no longer runs at all — every snapshot reaching
  the runner must carry the declaration, i.e. go through the mapper.
• Multi-root graphs are no longer legal, so the runner can't be embedded as a general
  DAG scheduler. The multi-entrypoint test was deleted rather than rewritten, and the
  two asymmetric-fan-in tests now fan out from a single start.
• Workflow has no entrypoint node is gone; a cycle with no root reports the missing
  start instead.

role landed as a union rather than a boolean isStart — it takes further roles
without another field.