fix(kanban): reclaim_task must not launder a blocked card into ready

[Kyzcreig]

Stacked on #71977 — this branch is based on
fix(kanban): make --initial-status blocked sticky against recompute_ready,
so the diff shown here includes that commit until #71977 merges. The two are
independent halves of the same hold-defeating bug (creation-time stickiness
vs. reclaim-time promotion); either can merge first, and this branch will
shrink to its own commit once #71977 lands. Review only
f511d3746 for this PR's change.

fix(kanban): reclaim must not launder a blocked card into ready

Stacked on the --initial-status blocked sticky fix. Review only the top
commit; the diff includes the base PR until it merges. The base PR is what
makes initial_status="blocked" sticky at all — without it, three of the
tests here can't distinguish this bug from that one. Merge order: base, then
this.

Symptom

An operator reclaim on a card parked in blocked promotes it to ready,
handing it straight to the dispatcher, which claims it and spawns a worker on
the next tick. This silently defeats every hold mechanism the board has:
--initial-status blocked, a worker's review-required handoff, and the
spawn-failure circuit breaker alike.

Root cause

hermes_cli/kanban_db.py, reclaim_task:

cur = conn.execute(
    "UPDATE tasks SET status = 'ready', claim_lock = NULL, "
    "claim_expires = NULL, worker_pid = NULL "
    "WHERE id = ? AND status IN ('running', 'ready', 'blocked') "
    "AND claim_lock IS ?",
    (task_id, prev_lock),
)

The WHERE clause accepts blocked while the SET writes an unconditional
literal 'ready'. A reclaim releases a claim; it is not a promotion.

The row it produces is worse than merely promoted: reclaim_task emits only a
reclaimed event, never unblocked, so _has_sticky_block still reports
True afterwards. The card ends up status='ready' and sticky-blocked
simultaneously — a state no other writer can produce, and one that
recompute_ready and the dispatcher disagree about.

Whole bug class

The sibling reclaim paths were already correct — release_stale_claims
(:4355), detect_crashed_workers (:7066, :7192), enforce_max_runtime (:7450)
and the failure-recording path (:7728) all scope their UPDATE to
status = 'running'. Only the operator-driven reclaim_task accepted a parking
status, so this is the whole class. A source-level invariant test pins that, so
a future writer widening a sibling's WHERE clause has to confront it.

triage and scheduled are the same category of pre-dispatch parking column
and get the same treatment. triage additionally gains the ability to be
reclaimed: it wasn't in the old WHERE clause at all, so a triage row carrying
stale claim residue simply returned False and stayed stuck.

Fix

• Rows in blocked / triage / scheduled keep their status and shed only
  the stale claim residue (claim_lock / claim_expires / worker_pid).
  unblock_task and promote_task remain the only ways out of blocked.
• The reclaimed event records status_preserved, so board history shows why
  a reclaimed blocked card did not go ready.
• hermes kanban reclaim reports the held status and points at unblock,
  instead of printing a bare Reclaimed <id> that reads as "it's queued again"
  and leaves the operator waiting for a worker forever.

No new state, no signature changes. +38/−4 across two files.

Tests

New tests/hermes_cli/test_kanban_reclaim_blocked_status_guard.py, 9 tests:

test	proves
..._initial_status_blocked_card	claim residue cleared, status held at blocked
test_dispatcher_does_not_spawn_a_reclaimed_blocked_card	E2E through a real dispatch_once: spawn_fn never called
..._coherent_with_sticky_block	no status='ready' + sticky-blocked row
..._preserves_worker_review_required_block	the review-required handoff survives
..._promote_a_triage_card	triage is now reclaimable and not promoted
test_no_claim_release_path_promotes_a_parked_row	source invariant over every claim-release UPDATE
..._records_the_preserved_status_in_board_history (control)	status_preserved in the event payload
test_reclaim_still_returns_a_running_task_to_ready (control)	primary contract unchanged: running → ready → dispatchable
test_cli_reclaim_tells_the_operator_the_card_is_still_held	CLI no longer prints a misleading bare success line

The running → ready → actually spawns control is deliberate: it caught an
earlier version of this suite that was false-greening on
skipped_nonspawnable (the dispatcher refuses assignees that aren't real
profiles, so "did not spawn" can pass trivially). The fixture patches
profile_exists so the negative assertions prove the status guard, not the
profile guard.

RED proof (both production changes reverted, tests unchanged): 7 of 9
fail. The two survivors are the controls. See TEST-EVIDENCE.md.

GREEN: 259 passed across test_kanban_db.py, this file,
test_kanban_decompose_db.py, test_kanban_worktree_isolation.py.

[Kyzcreig]

Base PR: #71977. Sibling independent fixes from the same pass: #71979 (stall-detector false positive), #71978 (worktree reuse ignoring the requested branch).

[teknium1]

Thanks — the main reclaim bug is real: hermes_cli/kanban_db.py:4486-4490 writes literal ready while accepting a locked blocked task.

Problems

• hermes_cli/kanban.py:1846 gives unblock guidance for triage, but unblock_task only accepts blocked and scheduled (hermes_cli/kanban_db.py:5808). A reclaimed triage card therefore receives a command that fails; its supported transition is the triage specify/decompose path (hermes_cli/kanban_db.py:5829).
• tests/hermes_cli/test_kanban_reclaim_blocked_status_guard.py:216 uses inspect.getsource() and regexes SQL. AGENTS.md:1382 explicitly bans source-code-reading tests because they test implementation shape rather than behavior.

Suggested changes

• Make the CLI remediation status-specific and add a triage-output regression test.
• Replace the source-regex test with behavioral tests for the actual claim-release paths.

Automated hermes-sweeper review.

[teknium1]

triage is included in this branch, but unblock_task only accepts blocked and scheduled (hermes_cli/kanban_db.py:5808). This prints a recovery command that fails for triage; direct triage to its specify/decompose transition instead.

[teknium1]

Please replace this source inspection with behavioral coverage. AGENTS.md bans tests that read production source because implementation-shape assertions break valid refactors without proving the runtime contract.

[Kyzcreig]

Closing — implemented on main.

Re-verified at 4209d371: reclaim_task no longer writes the unconditional literal this PR was filed against. hermes_cli/kanban_db.py:5157-5163 now computes retry_status = _retry_status_for_run(conn, task_id) and binds it as a parameter, with the guard WHERE ... status IN ('running','ready','blocked') retained. The SET status = 'ready' the root-cause section quotes is gone.

I also executed the laundering scenario end to end against a temp board on current main: a card blocked through the real block_task path lands status='blocked', claim_lock=NULL (kanban_db.py:6326), so reclaim_task returns False and the status holds at blocked. I could only reproduce a promotion by manufacturing claim_lock with a raw UPDATE, which no production writer does.

Branch preserved; reopenable if a genuine blocked-plus-claim path turns up.