fix(kanban): normalize stale same-lane worker handles

[flynn-zlr-bot]

Problem

The explicit same-lane Kanban recovery path correctly failed closed when worker_started_at remained non-null, but a terminal prior run could leave that fingerprint behind after every actual lifecycle handle (claim_lock, claim_expires, current_run_id, open run, worker_pid, and session_id) was gone. That stranded the exact authorized remediation card without proving a live worker.

Change

• add a board-kernel normalizer that atomically clears only isolated worker_started_at residue and appends durable lifecycle_normalized evidence
• preserve fail-closed refusal for non-READY state and every active claim/run/PID/session handle
• retain terminal heartbeat-only history without creating a phantom run or heartbeat
• keep ordinary active-PR suppression unchanged
• include the complete controller-only guarded same-lane resume OpenSpec and gated-launch implementation

Verification

• scripts/run_tests.sh tests/hermes_cli/test_kanban_same_lane_resume.py — 93 passed
• scripts/run_tests.sh tests/hermes_cli/test_kanban*.py — 449 passed, 2 existing Windows-only skips
• python -m py_compile on all changed Python files — passed
• ruff check on all changed Python files — passed
• git diff --check — passed

Boundaries

No Finance application/OpenSpec/data change, no PR #155 write/merge/deploy, no generic active-PR guard relaxation, no profile/gateway/infrastructure/configuration change, and no interaction with PR #37.

[Enough1122]

AI code review — automated follow-up for reference; not a maintainer.

The kernel is careful — CAS-guarded transitions, fail-closed refusals, a durable one-use receipt, compensation that confirms process-tree death before recording it. One blocker, about reachability rather than logic.

Nothing can invoke this (blocker).

kanban_db_dispatch.py:1582-1592 imports the whole surface — resume_same_lane, authorised_same_lane_request, SameLaneResumeRequest, SameLaneLaunchError, LinuxGatedChild — then never calls any of it. grep -n resume_same_lane in that 114 KB file returns exactly one line: the import. I fetched and grepped the sibling modules where a controller entry point would plausibly live — kanban.py, kanban_ops.py, kanban_swarm.py, kanban_diagnostics.py, kanban_db.py — and every one has zero hits for same_lane. The only two real call sites are internal: normalize_ready_worker_start_residue from kanban_same_lane_resume.py:1075, and _launch_same_lane_worker only from the launcher is None branch at :1127. The sole caller in the repo is tests/hermes_cli/test_kanban_same_lane_resume.py.

So there is no CLI verb, no tool, no RPC method and no dashboard route — only a hand-written import in a shell. For a change titled "fix(kanban): normalize stale same-lane worker handles", 4050 added lines ship the kernel and not the fix.

To be fair about the split: openspec/.../tasks.md:44 deliberately says "Add the explicit controller-only operation without wiring it into ordinary dispatcher scanning", and proposal.md:6 calls it "one controller-only operation". Not touching the dispatcher's duplicate-lane guard is right and I am not asking for it. The gap is narrower — "deliberately invoked" still needs an invocation to exist, and none does here. Either a minimal entry point ships in this diff, or the title should say the caller lands separately and name where.

Unverified / please confirm: post-image read at head df797f1, all four production files self-proofed (api .size == wc -c), base confirming all three modules are new. I did not run the test file. Note search/code does not index PR heads (a control term returns 7 hits, a symbol from this very PR returns 0), so the caller analysis comes from fetching the kanban modules directly. Please confirm whether an out-of-tree controller is expected to call this — if so this is a title/sequencing note rather than a blocker.