What the core executes, as a front end or a tool says it. Holds no
Tool: a tool the front end asks for is named — by its ToolName,
the route it labels, the field it edits — and built against the drawing
as it stands when the action is applied.
What a tool’s frame asks for: the next tool, seeded with whatever state
the hand-off carries — installed inside the same call and never sent
anywhere — or an action on the same terms a front end sends one.
One frame of a tool: preview, then act. The drivers call this and never
ToolTrait::widget directly, which is what makes the order structural —
a tool has no way to reach the preview writers from widget, because the
PreviewPhase they require is minted here and handed only to preview.
The interaction a frame hands its tool. A read-only session keeps the
pointer — selecting and navigating are free — but loses the two channels
that exist only to author: the held press every add-affordance arms from
(the new-pin markers, the route-start targets) and the Delete key. Taken
away here rather than in each of the tools that read them, so a new tool
cannot forget.
The selection tool a freshly renamed/moved pin should return to, so the pin
stays the standing target for further edits. A block pin returns to the
per-pin SelectPin selection; a port returns to its block-style
ResizeBlock selection.