fix(kanban): resume dependency waits on open PRs and allow READY requeue

[Kyzcreig]

Summary

A worker that opens a PR and then calls kanban_block(kind="dependency") cannot resume after its parents finish: the automatic promoted event does not count as a handoff, so check_respawn_guard returns active_pr on every tick. The PR is the continuation target in this case, not duplicate work.

• Permit exactly one continuation after a worker-origin dependency_wait followed by promoted, when the PR comment preceded the wait. A spawn after that promotion re-arms the original crash/reclaim guard. A newer PR comment also stays guarded.
• Add hermes kanban requeue <id> <reason> for an operator to explicitly retry a READY card without first blocking and unblocking it. Requeue requires a reason and an unclaimed READY card; it cannot override a newer PR comment, and a subsequent spawn re-arms the guard.

Reproduction and verification

Before the change, test_worker_dependency_wait_promoted_continues_pr_once fails: assert 'active_pr' is None after real block → parent completion → promotion. After the change:

36 passed in 8.74s
All checks passed!  # ruff on modified files
✅ All TUI-context subprocess calls have explicit stdin=

Tests cover worker dependency block, parent completion, promotion, post-continuation spawn-event null control, a newer PR comment, CLI requeue, invalid state, and operator retry reset. This ports the generic guard/CLI portion of ANG-Ventures#952; its fleet-specific #alerts notifier is not included upstream.

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Two independent changes; the "and" in the title is honest — I exercised each alone and each works without the other, sharing only the new after_comment_id plumbing. The comment-id correlation is the right fix for the same-second race, and the fail-closed sides hold: a payload that won't decode leaves the card guarded, a newer PR comment re-guards, cooldowns/blocker_auth are untouched by requeue, and the continuation re-arms exactly once.

1. requeue also lifts recent_success, not just active_pr — and nothing tests it. kanban_db_dispatch.py:1581 adds 'requeued' to the recent_success event list as a side effect. So hermes kanban requeue on a card that just completed a successful run clears recent_success for the whole guard window — a second, undocumented escape hatch. Mutating that list back to the pre-PR five kinds leaves the new file 13/13 green: no test covers it. kanban.md:1027 still says only "drag done→ready, unblock, re-promotion" lift it. If intended, add a line there and a test; if not, drop 'requeued' from :1581.

2. _append_event now crashes on a non-dict payload for four event kinds. kanban_db.py:1959-1962 does dict(payload or {}) for assigned/changes_requested/review_reopened/requeued. The signature is Optional[dict] but nothing enforces it. Every production site I traced passes a dict, so this is latent, not live — but it turns a bad row into a ValueError inside the caller's write_txn, failing the enclosing block/unblock rather than degrading. _json_dict at :67 already swallows the same case; worth matching.

3. The new command is invisible to agents and undocumented. requeue is added to kanban_parser.py:335 and _DELEGATED_CHILD_DENIED_ACTIONS (kanban.py:210), but there is no kanban_requeue in tools/kanban_tools_schemas.py/tools/kanban_tools.py, and grep -rn requeue website/ returns nothing — no kanban.md entry, no event-reference row for requeued. Consistent with "orchestrator-only", so not a blocker; flagged because the active_pr paragraph an operator reads when a card sits stuck never mentions the one command that unsticks it.