fix(kanban): forward concurrency caps from dashboard /dispatch endpoint

[rickhuizinga]

Problem

The dashboard's POST /dispatch endpoint (plugins/kanban/dashboard/plugin_api.py) calls dispatch_once() without forwarding max_in_progress_per_profile, max_in_progress, default_assignee, or failure_limit from the kanban config. When these parameters are None, the enforcement logic in _dispatch_once_locked skips the cap checks entirely.

This means the dashboard bypasses per-profile and global concurrency caps that the gateway tick and CLI correctly enforce.

Impact

The Desktop app's Kanban plugin auto-nudges the dispatcher after every board write (autoNudge in apps/desktop/src/plugins/kanban/api.ts — debounced 400ms, fire-and-forget). Every patchTask, createTask, deleteTask, bulkTasks, reassignTask, and reclaimTask call triggers a POST /dispatch.

Because the dashboard endpoint doesn't forward max_in_progress_per_profile, a user with kanban.max_in_progress_per_profile: 1 who creates or unblocks multiple tasks for the same profile through the Desktop Kanban plugin sees all of them spawn simultaneously, bypassing the cap. The gateway's 60-second tick enforces the cap correctly, but the dashboard's immediate dispatch circumvents it before the tick runs.

The old Dashboard web app does not have this problem — it only calls /dispatch when the user explicitly clicks "Nudge dispatcher".

Root Cause

Three callers invoke dispatch_once():

Caller	Forwards caps?
Gateway watcher (kanban_watchers.py)	Yes
CLI _cmd_dispatch (kanban.py)	Yes
Dashboard /dispatch (plugin_api.py)	No

Fix

Read the same config keys using the same _coerce_positive_int helper already used by the CLI path (kanban.py:_cmd_dispatch), then forward all four parameters to dispatch_once(). The config-reading block is copied verbatim from the CLI path to ensure identical semantics.

Parameters now forwarded

• max_in_progress_per_profile — per-profile concurrency cap ([Feature]: limit tasks per profile in kanban #21582)
• max_in_progress — global concurrency cap ([Bug]: hermes kanban dispatch command doesn't pass max_in_progress to dispatch_once #33488)
• default_assignee — fallback profile for unassigned ready tasks (feat(kanban): auto-assign unassigned ready tasks in dispatcher #27145)
• failure_limit — consecutive spawn failure threshold before auto-block

Backward compatibility

The try/except fallback (matching the CLI path) ensures that if load_config() fails, all caps fall back to None (disabled) — identical to the current behavior. Users without these config keys set see no change.

Follow-up (not in this PR)

The config-reading logic is now duplicated across three call sites. A future refactor could extract a shared dispatch_config_from_config() helper that returns a dataclass, so all three callers use one implementation.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #81382. Both patches pass configured Kanban concurrency caps into the dashboard dispatch path; #81382 is the earlier, broader, regression-tested implementation.

[rickhuizinga]

Thanks for the quick triage! Closing in favor of #81382 — it's more complete (regression tests, max=8 default removal). Found this independently while debugging concurrent task spawns on my homelab; glad to see it's already being addressed.