Describe the On start fallback of Run behavior (#230)

A nested behavior without a Behavior start node used to do nothing
when called. It now runs from its On start nodes.

- Behaviors: Run behavior starts at the On start nodes when the
  called behavior has no Behavior start, all of them in graph order.
- The Behavior end still returns its values. Such a call has no
  inputs, because only the start node declares them.
- The note on the node now reads "No start or On start node - does
  nothing" and only shows when neither exists.

Behaviors.md

@@ -203,8 +203,8 @@ shown on the node and editable in the inspector.
   `Object by name` taking the name the round put together (`"c" + index`). Two guards, not one:
   a pulse may take 100 000 steps (a loop legitimately runs long), but exec edges may only nest
   1000 deep — that is what catches a flow feeding back into itself before the call stack does.
-- **A behavior as a node** (nesting): a behavior that has a **Start** and an **End** node can be
-  run as a step of another behavior's graph. Every input declared on the start node becomes an
+- **A behavior as a node** (nesting): a behavior, usually one with a **Start** and an **End**
+  node, can be run as a step of another behavior's graph. Every input declared on the start node becomes an
   input port of the calling node, every output declared on the end node one of its outputs; the
   node is drawn under the behavior's own name, and the palette lists it there too, so a call is
   one pick. Declaring a port keeps both sides in step — renaming carries the typed-in value along,
@@ -213,6 +213,9 @@ shown on the node and editable in the inspector.
   variable defaults, so values travel in and out through the ports and nothing else. That makes a
   call repeatable and keeps a nested behavior free of hidden state. A behavior that would run
   itself raises an error instead of looping; there is one start and one end node per behavior.
+  A behavior **without a start node** is called from its **On start** nodes instead, all of them in
+  graph order, as when it starts on its own. It takes no inputs then, but its end node still hands
+  back what it is given. With a start node in the graph, its On start nodes stay out of the call.
 - **Keep** (a switch on each variable of the called behavior, in its inspector): a kept variable
   picks up where the last call **from this node, on this object** left it; the others start at
   their default every call. A variable added to a behavior starts out kept, and one from a project
@@ -231,8 +234,8 @@ shown on the node and editable in the inspector.
   stays in the same tab, and the trail belongs to that tab: a behavior opened any other way comes
   up in a tab of its own, without a trail, and switching back brings the trail back with it. And a call that cannot
   do anything **says so on the node** — no behavior picked, the behavior deleted,
-  or no start node in it. The last one is the one worth naming: without a start node there is no
-  way in, so the call is skipped and the flow simply carries on at its `exec` output. A missing
+  or neither a start node nor an On start in it. The last one is the one worth naming: without
+  either there is no way in, so the call is skipped and the flow simply carries on at its `exec` output. A missing
   *end* node is not a defect — a call is always synchronous, "done" is the nested flow running out,
   and the end node only decides what comes back.
 - **Shared state**: a **Variables asset** is a list of declarations and nothing else — no graph, no