Public termination endpoint for kanban runs (POST /runs/{run_id}/terminate)

Motivation

_terminate_reclaimed_worker in hermes_cli/kanban_db.py (~line 3057) already implements
SIGTERM → grace period → SIGKILL, but no HTTP route exposes it. The only user-facing
termination path today is POST /tasks/{task_id}/reclaim, which is a recovery action
for stuck/dead workers — not a clean "stop this running task" API. Operators who need to
cancel a live, well-behaved worker have no dashboard or API surface to do so without
SSHing into the host.

Adjacent evidence: issue #22176 (CLI interrupt /stop not working) shows user demand for
a stop primitive; a public terminate endpoint would satisfy the same need for tasks already
claimed and running.

Design options

Option A — Open endpoint
POST /runs/{run_id}/terminate sends SIGTERM (→ SIGKILL after grace) immediately. Any
authenticated dashboard caller can terminate any run. Simple; matches the "no RBAC layer"
reality of all other dashboard routes today. Downside: no audit trail, no signal to the
dispatcher that the task was deliberately cancelled vs. crashed.

Option B — Soft-cancel flag (proposed default)
POST /runs/{run_id}/terminate returns 202 immediately and sets a
runs.cancel_requested = 1 flag. The dispatcher's next tick reads the flag, sends SIGTERM,
waits for grace period, SIGKILLs if needed, and closes the run with outcome=cancelled.
?force=true skips the flag and sends SIGKILL directly. Advantages: dispatcher-mediated
semantics match how reclaim/claim work elsewhere; ?force documents destructive intent
explicitly; the flag survives a dashboard restart.

Option C — Scoped admin token
Destructive ops (terminate, kill) require a separate HERMES_ADMIN_TOKEN env var
distinct from the dashboard read token. Safer for shared deployments; adds operational
overhead for solo installs.

Proposed default

Option B. Soft-cancel + ?force escape hatch is the right trade-off: it preserves
dispatcher-mediated semantics (everything goes through the loop), gives the worker a clean
shutdown path, and the ?force flag makes SIGKILL an explicit opt-in rather than the
default. Option C can layer on top later if multi-user RBAC becomes a requirement.

Next steps

Will follow up with a PR implementing Option B after design preference is confirmed in this
thread. Read-only sibling endpoints (GET /workers/active, GET /runs/{run_id},
GET /runs/{run_id}/inspect) land in the companion PR (link to be added once opened).