fix(kanban): gate kanban-worker skill inject on true name-resolvability (fix Unknown skill(s) worker death)

[arakakileo]

Problem

Every dispatched kanban worker can die at startup with
ValueError: Unknown skill(s): kanban-worker, before the agent loop runs —
empty workspace, task reclaimed and respawned in a loop.

Root cause

The dispatcher injects --skills kanban-worker gated on
_kanban_worker_skill_available(HERMES_HOME), which tests file existence. The
worker resolves the skill by name via skill_view, which collects all
candidate SKILL.md files across the profile skills dir + the profile's
skills.external_dirs, and fails in two ways:

1. Not found — bundled skill is in the default root home, not every
   profile-scoped skills dir, and no external_dirs entry supplies it.
2. Ambiguous — the skill resolves to 2+ distinct files (e.g. a per-profile
   copy AND a copy reachable via external_dirs pointing at the root skills dir);
   skill_view refuses to guess.

The existence-only guard returns True in the ambiguous case, so the flag is
injected and the worker's resolver then refuses it. This is why copying the
skill into the profile dir made it worse — it forced the ambiguous branch.

Fix

Make the guard mirror the resolver: count distinct resolved
kanban-worker/SKILL.md files across the same search roots the worker uses
(profile skills dir + the profile's configured external_dirs, read from that
home's config.yaml), and inject only when exactly one resolves. Zero (missing)
and 2+ (ambiguous) both omit the flag. The mandatory kanban lifecycle still
ships via KANBAN_GUIDANCE, so dropping the supplementary skill is safe.

Healthy single-candidate profiles are unchanged (still inject).

Test plan

• Profile with a duplicate/ambiguous kanban-worker (external_dirs + own copy):
  guard now returns False, worker starts and completes (previously
  Unknown skill(s): kanban-worker).
• Profile missing the skill: guard returns False (unchanged outcome, no crash).
• Profile with a single canonical copy: guard returns True (unchanged).
• Adds tests/hermes_cli/test_kanban_worker_skill_inject.py.

Note for maintainers

#30025 generalizes this same guard into _skill_available_for_home for
task.skills but keeps the existence-only check, so it does not fix this
ambiguity case. If #30025 lands first, fold this distinct-candidate-count logic
into the shared helper so both the built-in inject and task.skills benefit.

[teknium1]

Thanks for tracing the ambiguous skill-resolution failure carefully.

Automated hermes-sweeper review found that current main already removes the entire failing auto-load path:

• 84e1d31e5 (refactor(kanban): fold worker/orchestrator skills into injected guidance) removed kanban-worker, _kanban_worker_skill_available, and the automatic --skills kanban-worker spawn argument.
• hermes_cli/kanban_db.py:8021-8040 now emits --skills only for explicit per-task skills.
• tests/hermes_cli/test_kanban_core_functionality.py:2768-2806 verifies a normal worker spawn has no auto-loaded skill.
• The lifecycle is now supplied directly through KANBAN_GUIDANCE (agent/prompt_builder.py:189, wired in agent/agent_init.py:1216-1219).

This shipped in v2026.7.1, so the reported kanban-worker ambiguity cannot occur on current main.