fix(kanban): make --initial-status blocked sticky from birth

[liuhao1024]

What does this PR do?

Makes hermes kanban create --initial-status blocked actually stick. The sticky-block gate (_has_sticky_block, from #28712) keys on the latest "blocked"/"unblocked" event row, but a task born blocked only ever wrote the status column — no event row. On the next dispatch tick, recompute_ready therefore treated it as event-less and auto-promoted it through promoted → claimed → spawned, starting the assignee ~21s after creation and bypassing exactly the setup/credential/deployment activation gate the caller had expressed (#91178). An explicit post-create hermes kanban block did persist, confirming the initial-block path was the only one missing the event.

The fix emits the block transition atomically inside the create transaction, with the same payload shape block_task writes (reason/kind/recurrences/source_status, plus initial: True to mark the origin), so an initial-blocked task follows the same lifecycle as a post-create block: sticky until an explicit unblock, invisible to the dispatcher's auto-recovery.

Related Issue

Fixes #91178

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/kanban_db.py — create_task's post-create hook now appends a "blocked" event row when initial_status == "blocked", inside the same write transaction as the create, with the kanban task created with --initial-status blocked is promoted and spawned #91178 rationale documented inline
• tests/hermes_cli/test_kanban_blocked_sticky.py — three regressions beside the existing kanban: dispatcher auto-promotes blocked task → respawn worker → protocol_violation loop #28712 sticky tests: an initial-blocked task has a durable sticky event and survives five recompute_ready ticks un-promoted; an explicit unblock still clears the gate and returns the task to the normal promotion path; and a plain created task stays event-less (the fix must not make every task sticky)

How to Test

1. .venv/bin/python -m pytest tests/hermes_cli/test_kanban_blocked_sticky.py -q — should pass (5 passed, including the three new)
2. Observed result: on unmodified main, test_initial_status_blocked_is_not_auto_promoted fails at the first sticky assertion — create_task(..., initial_status="blocked") leaves no "blocked" event row, _has_sticky_block returns False, and recompute_ready promotes the task on the first tick (the kanban task created with --initial-status blocked is promoted and spawned #91178 spawn-past-the-gate shape)
3. Regression: tests/hermes_cli/test_kanban_block_kinds.py + test_kanban_cli_dispatch_passthrough.py — 4 passed (block-kind routing and dispatch passthrough unchanged); the existing kanban: dispatcher auto-promotes blocked task → respawn worker → protocol_violation loop #28712 worker-block sticky tests still pass

Checklist

• Code follows the project's style guidelines
• Self-review completed
• Comments added for complex logic (why the event row is required for the sticky gate, and why it is atomic with the create)
• Tests added that prove the fix (sticky-from-birth + unblock clears + plain tasks stay auto-recover)
• All new and existing tests pass locally (5 + 4 passed)
• Platform: macOS (pure DB/event logic, platform-independent)

[alt-glitch]

This was generated by AI during triage.

Duplicate of #34735: both implement the same create-time blocked-event mechanism so initially blocked tasks remain sticky through recompute_ready.

[liuhao1024]

The slice 7/12 failure is an infra flake, not a test failure: the failing step in that job is "Install uv" — the runner failed to install the toolchain before any test executed, and no test name appears in the failure output. The only files this PR touches are hermes_cli/kanban_db.py (one event append inside an existing transaction) and tests/hermes_cli/test_kanban_blocked_sticky.py; neither is exercised by an install step.

I can't re-run checks as an outside contributor, so I've force-pushed a new commit SHA (3c3c654, content-identical to 7359be27a9 — amended committer date only) to trigger a fresh CI run, which is already queued.