fix(kanban): terminate worker process on block/archive/complete (#57596)

[liuhao1024]

What does this PR do?

Terminates the worker subprocess when a Kanban task transitions away from running via block_task, archive_task, or complete_task. Previously these functions cleared worker_pid in the database but never sent a signal to the actual process, leaving orphaned workers consuming CPU until manually killed.

The existing _terminate_reclaimed_worker() function (used by reclaim_task and release_stale_claims) is now also called from the status-transition paths.

Related Issue

Fixes #57596

Type of Change

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

Changes Made

• hermes_cli/kanban_db.py — block_task(): added worker_pid, claim_lock to initial SELECT; calls _terminate_reclaimed_worker() at both return paths (dependency block and normal block)
• hermes_cli/kanban_db.py — archive_task(): reads worker_pid, claim_lock before the UPDATE; calls _terminate_reclaimed_worker() after the DB transition
• hermes_cli/kanban_db.py — complete_task(): reads worker_pid, claim_lock before the UPDATE; calls _terminate_reclaimed_worker() after the DB transition
• plugins/kanban/dashboard/plugin_api.py — _set_status_direct(): added worker_pid, claim_lock to the SELECT; calls kanban_db._terminate_reclaimed_worker() when transitioning from running
• tests/hermes_cli/test_kanban_worker_termination.py — 7 new tests verifying termination is called for running→blocked/archived/done transitions and skipped when no PID is set

How to Test

1. Run pytest tests/hermes_cli/test_kanban_worker_termination.py -v — all 7 tests should pass
2. Run pytest tests/hermes_cli/test_kanban_block_kinds.py tests/hermes_cli/test_kanban_db.py tests/hermes_cli/test_kanban_core_functionality.py -q — all existing tests should pass (no regressions)
3. Manual: create a kanban task, let it reach running status with a worker, then archive it from the dashboard — the worker process should be terminated (no orphan)

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: macOS

Documentation & Housekeeping

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

[alt-glitch]

This was generated by AI during triage.

Duplicate of #31365 — same mechanism (calling _terminate_reclaimed_worker() from the running→blocked/archived/complete status-transition paths) and same two source files (hermes_cli/kanban_db.py, plugins/kanban/dashboard/plugin_api.py). #31365 (opened 2026-05-24) is the earliest open PR and covers a broader superset of manual exits from running. Related: #42858 (narrower archive_task-only variant) and the issue this fixes, #57596. Maintainer picks the canonical fix.

[liuhao1024]

Closing as superseded by #31365 — same mechanism (terminating live workers on manual running → done/blocked/scheduled/archived transitions), same source files (hermes_cli/kanban_db.py, plugins/kanban/dashboard/plugin_api.py), and #31365 was opened earlier (2026-05-24) with a more complete implementation including a shared _terminate_running_task_for_manual_exit() helper, signal_fn parameter plumbing, and self-completion skip guard.

The alt-glitch duplicate signal is correct here.