Workflow: real Bot-gated runs, kanban task queue, concurrency, assign to Workflow or Bot #1402

Problem

Today's @flybot/workflow run is mostly a demo player:

• plugins/workflow/client.js starts a setInterval that calls workflow/demo-step while playing.
• plugins/workflow/src/narrate.js posts canned progress (especially for the delivery template).
• #1380 spawns hidden ephemeral Bots and dispatch() sends one request, but node completion is not gated on the Bot's reply — the graph advances on demo-step / advance regardless.
• Each workflow holds one run in state.runs[workflowId]; a new assign() replaces it. There is no task queue and no multi-run concurrency.

Owner (2026-10-27): Workflow must really run. Kanban tasks should queue into a Workflow. Support a concurrency limit. Each board task can be assigned to one Workflow or one Bot.

Goals

0b. Loops + conditions — Support cycle edges with max-iterations/break, and conditional nodes that pick outbound edges from prior outputs (owner 2026-10-27).
0. Node I/O + ordered hand-off — Each node declares named inputs and outputs. Runs follow graph edges in order; upstream outputs become the next node's inputs. Refuse to start a node if a required input has no provider yet (owner 2026-10-27).

1. Real execution — Starting a run still spawns one hidden Bot per node (keep #1380). A node stays running until that Bot finishes the step (success → complete, failure → fail / retry policy). Remove auto demo-step playback as the default path for live runs (keep an explicit "Replay demo" if useful).
2. Kanban queue — Open board tasks assigned to a Workflow enter a FIFO queue for that Workflow. When a run slot frees, dequeue and start. Do not drop or overwrite a live run.
3. Concurrency — Configurable max concurrent runs per Workflow (default ≥1, owner-tunable; suggest default 2–3). Across Workflows, respect a host-level cap if cheap.
4. Assign target — Keep / harden board assign to either a Workflow or a local Bot (matcher + manual assign dialog). Bot match → that Bot owns/executes the card; Workflow match → enqueue a run.
5. UI — Workflow chat/flowchart show the active run; queue depth visible; no fake canned "完成了" unless the Bot actually reported it.

Out of scope

• Replacing the separate workflows/<id>.json engine (#1272).
• Changing panel image pack (Deployment already packing @flybot/workflow).

Acceptance

• Live run does not call demo-step on a timer.
• Node advances only after the ephemeral Bot's step result (or explicit fail/timeout policy).
• Second task assigned while at concurrency limit stays queued; starts when a slot frees.
• Assign dialog / matcher can target Workflow or Bot; Bot path does not start a Workflow run.
• Tests cover queue, concurrency cap, and Bot-gated advance (no reliance on narrate fixtures for live path).
• README EN+ZH describe real runs (not "v1 only posts progress").

Pointers

• plugins/workflow/src/service.js (assign, demoStep, handOff, settle, one-run state.runs)
• plugins/workflow/index.js (dispatch)
• plugins/workflow/client.js (play timer → demo-step)
• plugins/workflow/src/match.js, board assign modal
• Related: #1389 (handOff ignores no-sender), #1390 (concurrent assign orphans Bots), #1388 (reap)