fix(kanban): harden runtime recovery and worker startup

[qWaitCrypto]

What does this PR do?

This PR is a focused Kanban resubmission against current main.

After the earlier Kanban hardening work in #23334, main has since absorbed
many related Kanban PRs, including the create-time rejection path for toolset
names in task.skills and other dispatcher/runtime fixes. That made the older
stacked PR both partially superseded and broader than it needs to be now.

This PR intentionally narrows the scope and resubmits only the parts that still
add distinct value on top of current main:

• runtime diagnostics for persisted bad Kanban state
• narrow operator recovery commands
• worker startup ownership validation before any model API call

In other words, this is the reduced follow-up to #23334 after recent Kanban
changes landed separately on main.

Related Issue

Related to #22925, #22926, #22927.

Follow-up to #23334.

This PR is a narrowed resubmission after recent Kanban merges on main
superseded part of the earlier stack.

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

• Add read-only diagnostics for persisted bad task state:
  • invalid_task_skills
  • assignee_profile_not_found
  • stale_running_claim
• Add narrow operator recovery commands:
  • hermes kanban edit <task> --clear-skills
  • hermes kanban edit <task> --reset-failures
  • hermes kanban edit <task> --clear-claim
• Teach dispatch to skip ready tasks whose persisted task.skills already
  contain toolset names, while leaving the task ready for operator recovery
• Add a read-only worker startup guard so dispatcher-spawned workers verify:
  • task is still running
  • current_run_id still matches the worker's expected run
  • claim_lock still belongs to that worker
• Treat malformed Kanban worker ownership env as a benign startup-guard skip
  rather than silently disabling the ownership check
• Add targeted regression coverage for diagnostics, recovery actions, dispatch
  skip behavior, and worker startup ownership checks

How to Test

1. Run:
   pytest -q tests/hermes_cli/test_kanban_diagnostics.py
2. Run:
   pytest -q tests/hermes_cli/test_kanban_db.py
3. Run:
   pytest -q tests/hermes_cli/test_kanban_core_functionality.py tests/tools/test_kanban_tools.py tests/run_agent/test_kanban_worker_startup_guard.py

Local targeted results:

• tests/hermes_cli/test_kanban_diagnostics.py: 31 passed
• tests/hermes_cli/test_kanban_db.py: 82 passed
• tests/hermes_cli/test_kanban_core_functionality.py tests/tools/test_kanban_tools.py tests/run_agent/test_kanban_worker_startup_guard.py: 215 passed

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: Linux (WSL-style dev environment)

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

• Targeted Kanban/runtime verification passed locally