Feature: bidirectional visual connectors between panels + orchestration backend for user-opened terminals

[pdl-clay]

Summary

Add bidirectional visual connectors between panels on the canvas, plus a small orchestration backend inside the existing cate-orchestrator extension so the Cate Agent can drive panels connected to it — e.g. orchestrating several command-code terminals as Dev/QA workers.

The gap today

Cate already lets one terminal drive another through the cate CLI (cate terminal read / type / press), and the cate-orchestrator extension already manages Cate-owned coding-agent runs (create_coding_agent, send_to_coding_agent, …) in isolated worktrees. But there is no way to visually declare the topology of panels the user opened manually (e.g. two terminals running command-code, one as Dev, one as QA) and have the Cate Agent orchestrate those existing terminals.

Today the only way to convey the Dev/QA/Orchestrator topology is renaming panels or a separate note. There is no visual indicator of which terminal an agent controls, and no backend that makes "connect panel A to panel B, then orchestrate them" explicit and persistent.

Proposed behaviour

Phase 1 — visual connectors (bidirectional):

• Drag from a panel edge/anchor to another panel to create a connector (arrow/arc between panel centers, drawn in canvas-space, pans/zooms with the world).
• Connectors are bidirectional (QA↔Dev loops, orchestrator↔worker), selectable/deletable, optionally labelled, and persist in the workspace layout (.cate/workspace.json), like node positions already do.
• Connectors live as a sibling collection to nodes in the canvas snapshot — no change to CanvasNodeState/dockLayout (avoids the structural coupling noted in Feature: lightweight sticky notes on the canvas (file-less text nodes, Miro-style) #528).

Phase 2 — orchestration backend (inside cate-orchestrator):

• The Cate Agent discovers the connector topology via an internal host API (e.g. cate.flow.list) — because cate.terminal.* is currently first-party-only, discovery goes through a host API while control of workers goes through the first-party cate CLI (which already has granular permissions).
• New orchestrator tools: list connected panels, send a prompt to a connected worker (cate terminal type), read a worker's output (cate terminal read).
• Use case: user opens Terminal A (Dev, command-code) and Terminal B (QA, command-code), draws a connector from the Cate Agent panel to both, and asks "implement X, have QA verify it" — the agent delegates to Dev, reads QA's report, and loops.

Why it fits Cate

• The canvas is already the core surface, and connectors are a natural extension of the spatial model (same reasoning as Feature: visual connectors (arrows) between panels to show/define agent-to-agent flows #527, which asked for visual arrows).
• Panels already have stable ids and the layout already persists per-workspace in .cate/.
• It pairs directly with the existing cate CLI orchestration that has no visual counterpart today — and complements cate-orchestrator's Cate-owned runs by adding support for user-opened terminals as workers.

Scope note

This is deliberately bidirectional (not the directed arrows of #527) to cover QA↔Dev loops, and Phase 2 reuses the existing CLI + permissions instead of opening cate.terminal.* to arbitrary extensions.

Environment

• Cate 1.6.0, Linux (Arch), developer build from source