hermes - 💡(How to fix) Fix [Bug]: unlink_tasks does not trigger recompute_ready — tasks stuck in todo without dispatcher

Summary

unlink_tasks removes a parent→child dependency edge but does not trigger recompute_ready. This breaks the contract that "dependency changes should immediately re-evaluate promotion eligibility" — complete_task and unblock_task both do this, but unlink_tasks doesn't.

Steps to Reproduce

1. Create parent A, claim, complete → done
2. Create child B with parents=[A]   → A done → B starts ready
3. Create parent C, claim → running (not done)
4. link_tasks(C, B)   → C not done → B demoted ready→todo
5. unlink_tasks(C, B)  → removes C from B's dependencies
6. B now has only done parent A → should be ready

Expected Behavior

B promotes to ready immediately after unlink_tasks — same as when complete_task triggers recompute_ready for its children.

Actual Behavior

B stays todo indefinitely. It only promotes on the next dispatcher tick or a manual hermes kanban recompute.

Impact

• CLI-only users (no dispatcher): tasks stay permanently stuck. unlink + recompute must be run as two separate commands.
• With dispatcher: a tick delay (seconds) — minor but inconsistent with complete_task which is instant.
• Inconsistent API contract: complete_task and unblock_task both trigger immediate re-evaluation; unlink_tasks doesn't — users can't predict when their task will promote.

Workaround

Manually run hermes kanban recompute after hermes kanban unlink.

Proposed Fix

Add recompute_ready(conn) after the write txn in unlink_tasks, same pattern as complete_task and unblock_task.