fix(kanban): keep initial blocked tasks sticky

[opita04]

Summary

Keep explicitly blocked Kanban tasks sticky through readiness recomputation, while preserving manual promotion and later circuit-breaker recovery.

Changes

• atomically record an initial blocked event at task creation
• emit unblocked before promoted_manual
• add regressions for construction-barrier TOCTOU, event ordering, transaction rollback, manual promotion, and transient recovery

Why

Without durable initial-block provenance, recompute_ready() can promote a child while its graph is still being constructed if every currently attached parent is done.

Verification

• 400 relevant Kanban CLI/database/tool tests passed on current upstream main
• exact implementation/test bytes match the independently reviewed deployed-base patch
• independent review: PASS, no P0-P3 findings
• git diff --check: passed

[alt-glitch]

This was generated by AI during triage.

Related sticky-block implementations: this patch shares the create-time blocked-event mechanism but also changes manual-promotion event ordering, so it is competing work rather than a pure duplicate.

[teknium1]

Thanks for the focused Kanban regression coverage. Current main has the exact gap: create_task accepts initial_status="blocked" at hermes_cli/kanban_db.py:2585, but persists only the created event at hermes_cli/kanban_db.py:2670; recompute_ready relies on _has_sticky_block() at hermes_cli/kanban_db.py:3355 and otherwise promotes the blocked card at hermes_cli/kanban_db.py:3447.

The PR's create-time blocked event and manual-promotion unblocked event match that existing event-based contract. Its added tests cover the previously untested initial-status path, transaction rollback, ordering, and recovery behavior. No blocking issue was identified from the diff.

Automated hermes-sweeper review.