fix(kanban): recover cards guarded by stale PR evidence

[Oceanswave]

Summary

Fix Kanban cards that remain in Ready with no worker because the active-PR respawn guard treats every recent PR URL as proof that the card already ran.

• require prior run history before active_pr can guard a card
• let a strictly later explicit requeue supersede the latest PR comment
• include the real promoted_manual event in that requeue path
• expose respawn_guarded cards and reasons in hermes kanban dispatch --json and text output

Root cause

check_respawn_guard() previously returned active_pr for any recent PR URL in task comments. That incorrectly guarded first-run review/merge cards, and it ignored later unblock/promote/reclaim requests after a prior worker handed off a PR.

The dispatcher did retain (task_id, reason) in DispatchResult.respawn_guarded, but _cmd_dispatch omitted it from JSON and text output. Supervisors therefore saw a ready card with no worker but no machine-readable reason, which surfaced as stranded_in_ready and required manual diagnosis.

Tests

• tests/hermes_cli/test_kanban_active_pr_recovery.py: 10 passed
• tests/hermes_cli/test_kanban_cli_dispatch_passthrough.py: 2 passed
• tests/hermes_cli/test_kanban_db.py: 30 passed
• ruff check on changed files: passed
• py_compile on changed Python files: passed
• git diff --check: passed

The new regressions cover first-run PR references, prior-worker guarding, all explicit requeue event kinds, same-second fail-closed ordering, latest-comment precedence, and dispatch JSON observability.

Closes #80231.

Related active-PR guard work: #74432, #65996. This PR combines the first-run case with requeue recovery and the CLI observability needed by deterministic supervisors.

[spfcraze]

This was generated by AI during triage.

Summary:
The requeue kinds that supersede the active-PR guard include events written by automatic machinery (recompute_ready's promoted, release_stale_claims's reclaimed), so an automatic event after a PR comment can disable the guard on its own.

Problems:

• check_respawn_guard treats any later event of kind status/promoted/promoted_manual/unblocked/reclaimed as a continuation request, but kanban_db.py:4217 (recompute_ready) writes promoted automatically when a task's parents complete, and release_stale_claims (~4591) writes reclaimed when a worker's claim goes stale.
• After a worker opens a PR and the card returns to ready/blocked, one such automatic event disables the guard and the dispatcher respawns the task — the duplicate-PR outcome the guard exists to prevent; the PR body's "explicit requeue" wording is narrower than the implementation.

Solution:
Restrict the supersede set to operator-only kinds (promoted_manual, unblocked), or require an operator actor field on promoted/reclaimed before they count.

---

Checked against 314b6dd — the tip of fix/dispatch-respawn-guard-json-80231 when this was written — and 9d4ef04, main at the same moment.