fix(kanban): keep create-time blocked tasks sticky

[HeilbronAILabs]

Summary

• make initial_status="blocked" task creation emit a durable sticky blocked event in the same transaction
• backfill the sticky blocked event when idempotent creation reuses an older still-blocked row that lacks that event
• keep blocked rows out of ready recomputation/dispatch while preserving normal ready task dispatch and blocked cleanup behavior

Verification

• python -m py_compile hermes_cli/kanban_db.py tests/hermes_cli/test_kanban_blocked_sticky.py
• git diff --check upstream/main...HEAD
• isolated temp-Kanban CLI proof covering blocked create, idempotent legacy backfill, dispatch exclusion, normal ready control dispatch, and blocked cleanup

Notes

This is a source candidate only. It has not been applied to any installed or live Hermes runtime.

The local environment used for verification did not have pytest available, so the focused pytest file was not run here. Maintainers should run the targeted tests/full suite in a dev environment with test dependencies installed before merge.

[alt-glitch]

This was generated by AI during triage.

Related to #34735, #41497, and #70733: this shares the create-time blocked-event repair but adds an idempotent-reuse backfill for legacy blocked rows. Please consolidate the competing sticky-block implementations rather than treating this as a duplicate.

[teknium1]

Thanks for the focused fix. The premise remains valid on current main: create_task() stores initial_status="blocked" at hermes_cli/kanban_db.py:3084 but emits only created at hermes_cli/kanban_db.py:3172-3191; _has_sticky_block() therefore returns false without a lifecycle marker (hermes_cli/kanban_db.py:3950-3985), and the dispatcher invokes recompute_ready() before selection (hermes_cli/kanban_db.py:8196). The new atomic blocked event fits the existing sticky-block contract, and the idempotent legacy-row backfill is appropriately limited to a still-blocked row retried with initial_status="blocked".

Problems

• The test hunk needs manual salvage placement because current main’s tests/hermes_cli/test_kanban_blocked_sticky.py was pruned by 39975613b13b418e0eceda178434d7be90ad4f91 and no longer contains the PR’s line-271 context.

Suggested changes

• Preserve both proposed regression cases when resolving that test conflict, then validate with the repository test wrapper.

Automated hermes-sweeper review.