fix(plugins): stop kanban dashboard nudge from exceeding max_in_progress

[fangliquanflq]

What does this PR do?

Fixes the Kanban dashboard Nudge dispatcher path so it honors kanban.max_in_progress (and per-profile caps). Previously a single UI nudge could push a board past the configured running limit (default nudge budget was 8) even when the gateway tick respected the cap.

Symptom

Operators set kanban.max_in_progress: 3, gateway logs show the cap loaded, but after a dashboard nudge the board can show ~8 tasks in running.

Impact

Resource-constrained hosts / local models get more concurrent workers than configured, which can pile up timeouts, rate limits, and stalled capacity. Anyone using the dashboard nudge with max_in_progress set is affected.

Bug Cause

Trigger: plugins/kanban/dashboard/plugin_api.py dispatch() - historical max_n: Query(8) passed only as max_spawn to dispatch_once.

Causal chain:

1. Operator clicks Nudge dispatcher (or calls POST /api/plugins/kanban/dispatch).
2. Handler calls dispatch_once(..., max_spawn=8) with max_in_progress=None.
3. dispatch_once treats max_spawn as a live concurrency budget (running + spawned), so the board can climb to ~8 running tasks.

Why it is wrong: max_spawn is not a substitute for max_in_progress. The board-wide / per-profile caps must be passed explicitly; omitting them means unlimited for those checks.

Working sibling / contrast: Gateway watcher and hermes kanban dispatch already pass max_in_progress / max_in_progress_per_profile from config (#34337 for CLI).

Ruled out: Config not loaded by the gateway - dispatcher logs showed max_in_progress=3 while the board still exceeded the cap after nudge-style bursts.

Fix

Dashboard /dispatch loads the same concurrency knobs from config as CLI/gateway. ?max= only overrides max_spawn (including 0 = spawn nothing this tick); it does not bypass max_in_progress. Negative max returns 422.

Related Issue

Fixes #81381

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Changes Made

• plugins/kanban/dashboard/plugin_api.py - pass max_in_progress, max_in_progress_per_profile, default_assignee, and config max_spawn into dispatch_once; stop defaulting nudge max to 8
• tests/plugins/test_kanban_dashboard_plugin.py - regression coverage for config passthrough, ?max= override, and max=0

How to Test

1. python -m pytest tests/plugins/test_kanban_dashboard_plugin.py -k test_dispatch -q
2. With kanban.max_in_progress: 3, put 5+ ready tasks on a board, call POST /api/plugins/kanban/dispatch, confirm running count does not exceed 3.
3. Call the same endpoint with ?max=0 and confirm no new spawns while the cap args still arrive.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) - N/A (docstring on the endpoint only)
• I've updated cli-config.yaml.example if I added/changed config keys - N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows - N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior - N/A

[fangliquanflq]

CI flake note: slice 3 failed on unrelated tests/test_tui_gateway_server.py::test_write_json_serializes_concurrent_writes (asserted 9 lines vs 8). This PR only touches kanban dashboard dispatch caps. Please re-run failed jobs if you have Actions write access.