feat: Let the AI see and arrange the canvas

[camielvs]

Description

The assistant had no idea where anything was. Nodes carry a position on the canvas, and
none of it reached the model, so it could neither describe the layout nor do anything
about it. New steps were placed to the right of whatever already existed — fine for one,
but ask for a five-stage pipeline and you got a straight horizontal line to rearrange by
hand.

Positions now appear alongside every task, input, output and sticky note. These are the
resolved positions — where the node is actually drawn — so a pipeline imported from YAML
with no saved layout reports the coordinates the user is looking at rather than nothing
at all.

Two new abilities. move_node nudges a single task, port or note — the targeted fix for
one thing overlapping another. auto_layout arranges the whole graph along its
connections, and it is the editor's own auto-layout rather than a second implementation,
so you get exactly what View > Auto-layout gives you, right down to the choice of
algorithm. That matters more than it sounds: the arrangement depends on the rendered size
of each node, which only the live canvas knows.

Both limits of auto-layout are in the prompts rather than left to be discovered. It only
arranges the graph on screen, so after building inside a subgraph the assistant says the
layout has not been applied there instead of claiming a tidy canvas. And it moves sticky
notes along with everything else, so it is told to read them first and to mention that it
rearranged them. Repair is told layout is not correctness and not to tidy the canvas as a
flourish after a fix.

The run view keeps its read-only stance: it gains the positions in what it reads and
neither of the two writes.

Related Issue and Pull requests

Second of five. Stacked on the sticky-notes PR below it, which is where the
stickyNotes payload that auto_layout is told to read comes from.

Type of Change

• New feature

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Test Instructions

1. Ask the assistant to describe where things are on the canvas — it should give real
   relative positions, not guesses.
2. Drag two steps so they overlap, then ask it to fix the overlap. It should move one
   with move_node, not rearrange the whole graph.
3. Ask it to build a multi-stage pipeline from scratch, then ask it to tidy the canvas.
   The result should match what Cmd/Ctrl+Shift+L gives you.
4. Ask for a specific layout style ("lay it out with dwyer") — it should pass that
   algorithm through.
5. With a sticky note on the canvas, ask it to auto-layout: the note should move with
   everything else, and it should say so in its reply.
6. Ask it to auto-layout while you are looking at the top level after it built something
   inside a subgraph — it should say the subgraph was not laid out rather than implying it
   was.
7. Try to move a locked sticky note — it should refuse and say it is locked.
8. Ask it to move a connection — it should explain a connection has no position of its own.
9. In the run view, ask it to move something — read-only message.

🤖 Generated with Claude Code

[github-actions]

🎩 Preview

A preview build has been created at: ai-canvas-layout/11133e5

[camielvs]

Correctness pass over the branch (diff against ai-sticky-notes). Typecheck, eslint and all three touched test files pass; the findings below came from reading the new code against the surrounding canvas/registry machinery plus two throwaway probes.

Seven findings inline, ranked roughly by severity. Two things to flag up front:

The module-init cycle is the blocking one. The new editorRegistry import makes csomBridge.ts throw TypeError: NodeTypeRegistry is not a constructor when it is the first module imported — verified failing on this branch, passing on base. It is masked purely by import order in toolBridge/index.ts, so it will surface on an unrelated refactor or on any test that imports the bridge directly.

(0,0) means "unset" throughout the codebase, and two findings here are downstream of that (move_node to the origin, and unplaced nodes in the serializer). #2766 has a third. resolvePosition substitutes an index-based default for the origin, so the position the model reads and the position the user sees can disagree on any pipeline without a saved layout. Probably one shared decision rather than three local fixes: either report the resolved position to the model, or give the AI-side paths the same resolvePosition treatment the rest of the canvas uses.