A transition carries a name, so a state needs no visible port (#52)

A state keeps its `in`/`out` exec pins in the model and the editor never draws
them. That is the whole trick: connecting, undo, deleting a state and saving all
keep working untouched, because `normalizeGraph` filters nodes and never edges,
and no edge ever checks its port key against a NodeDef. Only two places change --
`NodeView.redraw` stops drawing the row, and `portAt` refuses to hand one out, so
an invisible pin cannot be grabbed either.

Transitions are drawn by right-clicking a state, `Make transition`, then clicking
the target. The armed mode takes the same shape as a live drag, so the existing
preview draws it with no second code path, and it dies with Escape, a click on
empty canvas or a switch to another asset.

Removing the pins removed the only handle a transition had: edges have no
hit-test anywhere, and the pin right-click was the sole route to Disconnect.
The inspector's TRANSITIONS OUT / TRANSITIONS IN lists are therefore not a
convenience, they are the delete path.

`GraphEdge` gained an optional `label`, which `normalizeGraph` has to pass
through explicitly or a saved name is dropped on load. `State transition`
replaces `Next state`: it takes the machine on an input port and the name from a
picker, and resolves against the *current* state. Names are deliberately not
unique across a machine -- two states may both have an `alarm` -- so a node named
`alarm` moves whichever state has one, and an empty name follows the single
unnamed edge.

The geometry moved to a Pixi-free `transitions.ts`: a gap to the box border, and
a fan that puts a pair of opposite edges beside each other instead of on top of
each other. Keeping it as plain maths is what let a screenshot bug become a unit
test -- an earlier pin-to-pin line ran under the target node and took its
arrowhead with it, because `nodeLayer` sits above `edgeLayer`.

One limit stands and is not fixed here: `ConnectCommand` rejects a second edge
between the same two states ("Already connected"), because every transition
hangs off the same two ports. With names, `A --alarm--> B` beside
`A --seen--> B` is a sensible pair, so this is worth its own issue.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/core/graph/NodeRegistry.ts

@@ -91,6 +91,12 @@ export interface NodeDef {
   declaresPorts?: 'inputs' | 'outputs' | 'both';
   /** How a declared port becomes a port; without it, named after its key and typed by its kind. */
   declaredPort?(port: DeclaredPort, node: GraphNode): PortDef;
+  /**
+   * Edges between two such nodes are transitions: drawn as a straight arrow instead of the usual
+   * curve, and hung on ports that are never shown. A transition graph is read as directed steps
+   * between whole states, not as signal flowing left to right into a particular socket.
+   */
+  transitionEdges?: true;
   /**
    * Ports this node computes beyond the fixed and the declared ones – how many outputs a Sequence
    * offers, which values the behavior a call node names takes. `resolveDef` applies it.
@@ -105,7 +111,8 @@ export interface NodeDef {
   /**
    * Event nodes have no `run` – the interpreter seeds their outputs. `def` is resolved for the node at
    * hand, the only way a node with derived ports knows how many it has. `entry` is the exec input
-   * the pulse arrived through – what a node with one exec input per meaning reads.
+   * the pulse arrived through – what a node with one exec input per meaning reads. `lookup` is the
+   * project around the graph, for a node whose step is written in another asset.
    */
   run?(
     ctx: NodeContext,
@@ -113,6 +120,7 @@ export interface NodeDef {
     params: PropertyBag,
     def: NodeDef,
     entry: string,
+    lookup: GraphLookup,
   ): RunResult;
 }