feat(workflow): Settings control for per-Workflow concurrency; remove host-wide live-run cap #1525

Written-by: FlyBot Product

Ask (owner, 2026-10-28)

1. Workflow concurrency must be configurable in Settings (not only via API / read-only Details).
2. No system-wide total concurrency limit — remove the host-wide live-run cap so only each Workflow's own setting gates starts.

Current behaviour (main)

• Per Workflow: maxConcurrent default 2, clamped 1–8 (MAX_CONCURRENT), set via workflow/concurrency / create.
• Stage Details shows Concurrent runs as a read-only kv (plugins/workflow/client.js); Settings graph UI has no editor for it.
• Host-wide: HOST_CAP = 6 in plugins/workflow/src/service.js — drainSync / drainAll / assign gate refuse to start another live run once any combination of Workflows already has 6 live runs. Tasks queue even when a Workflow still has room under its own maxConcurrent.

Expected

• Settings → Workflows (graph / Details / inspector — match existing Settings polish) lets the owner set that Workflow's concurrent live runs, persists through workflow/concurrency (or equivalent), and the stage reflects the new value.
• Remove HOST_CAP / the cross-Workflow live-run ceiling. Starting a run is gated only by that Workflow's maxConcurrent (and queue / pause / fail rules as today).
• Keep a sensible per-Workflow floor (≥1). Raise or drop the hard 1–8 ceiling if it blocks a reasonable Settings value; document the chosen bound (or “unbounded integer ≥1”) in the subsystem doc / README.
• Lowering the cap still must not stop runs already started (existing rule).
• changelog + docs per repo rules; regression tests for: Settings write round-trip, drain ignores any former host cap, per-Workflow cap still queues when that Workflow is full.

Out of scope

• Prod upgrade.
• Changing node-Bot permissions (fix(workflow): node Bots inherit full normal-Bot permissions #1512) or Chief reply leak (fix(workflow): ephemeral node Bot replies still land in Chief / persistent Bot chat as queued 「Reply from …」 #1524).

Acceptance

• Owner can change a Workflow's concurrency from Settings without calling the API by hand.
• With several Workflows each under their own cap, the host never blocks a start solely because “total live runs ≥ 6”.
• Tests cover Settings/API set + absent host cap; README/subsystem doc updated.