Problem

Hermes Kanban currently has a gap between the dependency engine and the public CLI: routine recovery/cleanup sometimes requires direct SQLite writes to promote a card from todo to ready.

Concrete local case:

• An organizational parent was closed as done after its children had already been created.
• The children remained todo because the parent transition was performed as a direct DB repair / terminal-state cleanup rather than through a public command path that fired promotion semantics.
• To recover, the operator had to run a narrow SQL update like:

UPDATE tasks
SET status='ready'
WHERE id IN (...)
  AND status='todo';

That works, but it bypasses the normal CLI/audit surface and is too sharp for an operation that has become a repeated maintenance pattern.

Desired CLI

Add a first-class command for explicit, audited promotion, for example:

hermes kanban --board <board> promote <task_id>   --from todo   --to ready   --reason "parent organizational cleanup"

Alternative shape if it fits the existing model better:

hermes kanban --board <board> claim <task_id> --force-if-parents-done
# or
hermes kanban --board <board> claim <task_id> --force-promote

I slightly prefer promote because assignment/claiming and lifecycle promotion are separate concepts.

Expected behavior

1. Refuse promotion when dependencies/parents are not satisfied, unless an explicit --force flag is provided.
2. Emit a durable task_events entry, e.g. promoted_manual, including actor and reason.
3. Do not implicitly assign the card. Promotion should allow the safe parking pattern: ready + unassigned.
4. Support --json output for scripts and recovery tooling.
5. Ideally support --dry-run so operators can inspect whether promotion would be allowed before mutating state.

Why this matters

This is especially useful for anti-respawn Kanban workflows:

• Close an organizational parent.
• Promote all children to visible ready state.
• Keep only the current/active child assigned.
• Park future sequential children as ready + unassigned so the dispatcher skips them.

Today this can require direct DB mutation, followed by dispatch --dry-run verification. A CLI command would preserve the same safety while keeping the operation inside Hermes' public/audited interface.

Acceptance criteria

• todo -> ready recovery can be done without raw sqlite3 writes.
• Normal dependency checks are preserved.
• Force mode, if implemented, is explicit and audited.
• Promotion does not imply assignment.
• The command is documented in hermes kanban --help and returns machine-readable JSON.