fix: keep initially blocked kanban tasks sticky

[JVibez-D]

Summary

• Preserve the initial blocked Kanban state as sticky metadata when tasks are inserted.
• Add regression coverage for initially blocked tasks so dispatcher/status transitions do not accidentally treat them as ordinary queued work.

Test Plan

• python -m pytest tests/hermes_cli/test_kanban_blocked_sticky.py

Notes

• Branch pushed from fork: JVibez-D:jovex/kanban-initial-blocked-sticky

[teknium1]

Thanks for the focused Kanban-state fix. The premise remains valid on current main: create_task() records status="blocked" for initial_status="blocked" at hermes_cli/kanban_db.py:2585, but only emits the created event at hermes_cli/kanban_db.py:2670-2683. _has_sticky_block() therefore returns false without a blocked lifecycle event (hermes_cli/kanban_db.py:3273-3279), allowing recompute_ready() to promote the task (hermes_cli/kanban_db.py:3317-3365).

The added event makes the existing sticky-block guard cover the create-time path, and the regression test exercises the relevant create → recompute behavior. The branch is substantially behind main, but the salvage is mechanical: place the narrow event append after the current created event.

Automated hermes-sweeper review.