fix(kanban): keep initially blocked children sticky

[isacstelian]

Summary

• keep children created with initial_status="blocked" sticky when their parents complete
• recognize audited operator overrides (unblocked, manual promotion, and dashboard status moves) so circuit-breaker recovery still works
• add isolated temp-HERMES_HOME coverage for parent completion, claim prevention, explicit unblock, normal dependency promotion, and the real dashboard PATCH path

Root cause

create_task(initial_status="blocked") records the gate only in the created event payload. _has_sticky_block() previously inspected only blocked/unblocked events, so recompute_ready() treated the child as a recoverable circuit-breaker block and promoted it after the parent completed.

Test plan

• RED reproduction: blocked child became ready after parent completion on origin/main
• scripts/run_tests.sh tests/hermes_cli/test_kanban_blocked_sticky.py -q (5 passed)
• focused Kanban/dashboard regression set (54 passed, 1 skipped)
• Ruff on both changed files
• full repository suite completed on the same SHA: 77 failures across 26 unrelated files, with no Kanban failure; test_health_detailed_returns_ok reproduces on clean origin/main, and the remaining failures are outside this diff (timing/load, optional providers, and host-policy fixtures)

The PR remains draft because the full baseline is not green and GitHub reported no checks for the fork branch.

Internal tracking: IT-52.

[alt-glitch]

This was generated by AI during triage.

Related competing work: #34735 emits a synthetic blocked event, while #64830 and this PR interpret the creation audit state. This PR also models later manual/dashboard transitions; maintainers should select or consolidate the sticky-block design.