fix(kanban): report and document actual unblock status

[helix4u]

What does this PR do?

Makes kanban_unblock report and document the status that the database actually assigns. An unblocked task moves to ready only when all parents are done; otherwise it remains dependency-gated in todo.

The handler previously returned status="ready" unconditionally, and its schema, CLI help, and two documentation tables repeated that guarantee even though kanban_db.unblock_task() deliberately routes tasks with unfinished parents to todo.

This preserves Dusk1e's original fix and commit authorship from #28728, then completes the requested schema and documentation updates.

Related Issue

Supersedes #28728

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Return the task's persisted post-unblock status from tools/kanban_tools.py.
• Add regression coverage for unblocking a child whose parent is still open.
• Describe the ready/todo routing accurately in the tool schema and docstring.
• Align the CLI help and Kanban tool reference/user guide with the database behavior.

How to Test

1. Create a parent task and a blocked child linked to that parent.
2. Call kanban_unblock for the child while the parent is unfinished.
3. Confirm both the tool response and persisted task status are todo; the existing happy-path coverage confirms a task without unfinished parents returns ready.

Local verification performed: python -m compileall -q tools/kanban_tools.py hermes_cli/kanban.py and git diff --check. Pytest was not run locally due the workstation's test-runner safety restriction; the targeted regression test is included for CI.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11 (static verification)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Not applicable.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #28728 — both return the persisted kanban_unblock status rather than hard-coding ready. This PR additionally updates the surrounding documentation and schema wording.

[helix4u]

This was generated by AI during triage.

Duplicate of #28728 — both return the persisted kanban_unblock status rather than hard-coding ready. This PR additionally updates the surrounding documentation and schema wording.

any way we can do these after ready to review and not in draft? same question with the classifier. and would love it if it identified new docs gaps introduced in a PR.

[teknium1]

Merged via #66571 (rebase, so your docs(kanban): clarify unblock status routing commit and Dusk1e's original fix are both preserved in history). Added a follow-up commit documenting the recurrence→triage loop-breaker at the human-facing lifecycle level, since that was the actual source of the reporter's 'unpredictable triage' confusion. Thanks @helix4u and @Dusk1e.