fix(kanban): report actual unblock status + document triage escalation

[teknium1]

Summary

kanban_unblock now reports the status the DB actually assigns, and the docs explain why an unblocked task can later land in triage.

Salvage of #66503 (which superseded #28728). Preserves Dusk1e's original response-status fix and Gille's doc clarification, then completes the missing piece: the reporter's real confusion — "I unblock a task and it unpredictably ends up in Triage" — was never documented at the human-facing lifecycle level.

Root cause of the reporter's symptom: unblock_task only ever routes to ready (all parents done) or todo (a parent still open). It never touches triage. The task reaching triage is a subsequent same-cause re-block hitting BLOCK_RECURRENCE_LIMIT (default 2) — a deterministic loop-breaker, not an LLM judgment call, and a task's body text cannot opt out of it (the recurrence counter deliberately survives each unblock).

Changes

• tools/kanban_tools.py: _handle_unblock returns the persisted status via get_task() instead of hardcoding ready; schema + docstring updated.
• hermes_cli/kanban.py: CLI help reflects ready/todo routing.
• website/docs/reference/tools-reference.md + website/docs/user-guide/features/kanban.md: table entries corrected.
• website/docs/user-guide/features/kanban.md: new "Where an unblocked task lands" note explaining the ready/todo split AND the recurrence→triage loop-breaker (the actual user confusion).
• tests/tools/test_kanban_tools.py: regression test — unblock with an unfinished parent returns todo.

Validation

Live E2E against a temp HERMES_HOME with the real kanban_db:

Scenario	Tool response	Persisted status
unblock, all parents done	ready	ready
unblock, parent still open	todo	todo
block → unblock → re-block (same cause, ×2)	—	triage

Targeted tests: scripts/run_tests.sh tests/tools/test_kanban_tools.py -k unblock → 5 passed.

Infographic