🐛 fix(kanban): clear the active_pr respawn guard on an outer-loop feedback bounce

[cwest]

Why

The OUTER feedback loop — a human's feedback on an accepted card, routed back to the author for a revision — had no code path that cleared the active_pr respawn guard, so it wedged every time and required a hand-run block→unblock→reassign dance.

Root cause (hermes_cli/kanban_db.py):

• The INNER review-bounce loop self-heals via auto_route_review_bounce, but it fires ONLY for the review-changes-requested reason. A human-feedback bounce is a different reason, so it never fires.
• A raw move_card blocked/acceptance → ready emits only status_changed, never the unblocked cutoff event check_respawn_guard honors. So the guard stays active_pr (the PR is genuinely open) and the dispatcher refuses to spawn the author every tick (respawn_guarded {active_pr}).
• Repeated churn inflates block_recurrences past BLOCK_RECURRENCE_LIMIT → the loop breaker escalates the card to triage, where a naive block→unblock cutoff silently no-ops.

What

Adds route_feedback_to_author, a sanctioned caller-driven primitive that performs the whole outer-loop bounce atomically, composed from existing sanctioned building blocks so the INNER loop, the reviewer PASS → acceptance path (accept_task), and the merge → done path are all left unchanged:

1. reset_block_recurrences — frees a triage card and prevents immediate re-escalation on the next same-cause block;
2. reassign to the author (emits assigned), fenced on the card still being in a transitionable lane (blocked / scheduled / triage);
3. unblock_task — emits the unblocked cutoff event NOW, causally AFTER the PR-URL handoff comment, which becomes the pr_cutoff check_respawn_guard honors so the active_pr (and recent_success) guard clears and the next dispatch spawns the author;
4. recompute_ready + an [audit] comment naming the PR + feedback.

Recovers a card from blocked, acceptance (blocked + acceptance owner), AND triage. Idempotent: once routed off the parked lane, a second call is a clean no-op (returns False, no duplicate audit comment). A blank author raises rather than guessing; a missing card returns False.

The triage-transition half of unblock_task is already live (it accepts blocked / scheduled / triage), so this change is scoped to the outer-loop auto-clear primitive only — it does not re-implement the triage transition.

Testing

New behavior-contract tests (tests/hermes_cli/test_kanban_route_feedback_to_author.py, 9 tests):

• guard cleared from the acceptance lane (check_respawn_guard(...) is None after the route);
• the routed card is genuinely dispatchable via the real dispatch_once spawn path (not a live spawn);
• recovery from triage with an inflated block_recurrences (counter reset to 0);
• recovery from a plain blocked lane;
• an audit comment records the route and names the PR;
• idempotency (one route, one audit comment);
• a blank author raises; a missing card returns False;
• a regression guard that the INNER auto_route_review_bounce path still works.

RED check: reverting the unblock_task cutoff step leaves the guard active_pr and the guard-clear tests fail — proving the cutoff emission is the load-bearing behavior.

Full tests/hermes_cli/test_kanban_db.py (280) and the surrounding kanban lifecycle suites pass with zero regressions. (One pre-existing macOS-only test, test_signal_handler_kanban_worker.py, depends on Linux /proc for PID liveness and cannot pass on Darwin; it is byte-identical to base and unrelated to this change.)

[cwest]

The primitive is built entirely from existing sanctioned pieces, and each one behaves the way this code relies on. reset_block_recurrences frees a triage card and zeroes the loop counter; the fenced reassign emits the assigned event; unblock_task accepts blocked/scheduled/triage and writes the unblocked event now, causally after the PR-URL handoff comment. That ordering is the whole mechanism: check_respawn_guard sets its pr_cutoff to max(24h window, latest unblocked ts), so an unblock stamped after the PR comment pushes the comment out of the scan window and the active_pr guard clears. Same story for recent_success. Read the guard against integration HEAD and it lines up exactly.

Scope is right. The triage transition in unblock_task is already live, and this change doesn't re-touch it. Nothing wires the primitive into a live dispatch path yet, which matches the plan to add the caller separately. The inner auto_route_review_bounce path, accept_task, and the merge-to-done path are all left alone, and the surrounding kanban suite stays green.

Tests assert behavior, not snapshots: guard cleared from the acceptance lane, the routed card actually spawning through dispatch_once, triage recovery with the counter reset, idempotency, the blank-author raise, the missing-card no-op. I reproduced the RED check independently by removing the unblock step from a scratch copy of the file: five tests fail with the guard still active, which is the load-bearing behavior. Restored, then ran the new file (9 pass) and test_kanban_db.py (271 pass). All CI checks pass on this SHA.

No changes needed.