hermes - 💡(How to fix) Fix [Feature]: Task tagging / structured metadata for kanban tasks

Problem

Currently, kanban tasks have a single free-text body field and a set of fixed attributes (assignee, priority, status, skills, etc.). There is no way to attach structured, filterable metadata to a task — for example, tags like run-at-night, owner:backend, or blocked:api-down.

This matters when an automated dispatcher or cron worker needs to select a specific subset of tasks based on task characteristics, not just status. For example:

Use case — time-gated task execution:

A cron job fires every night at a fixed time. It should only pick up tasks that are:

1. Currently blocked (not ready to auto-run during the day)
2. Tagged as run-at-night (explicitly marked as night-worker eligible)

All other blocked tasks — those waiting on an API, on human input, or on a dependency — should be left alone. Without tagging, the dispatcher cannot distinguish between a task that is blocked because it should run at night vs. a task that is blocked because it cannot proceed yet.

Today, the only workaround is encoding tags as a structured prefix in the body field (e.g., Tags: run-at-night), which is fragile and not machine-filterable at the kanban layer.

Proposed Solution

Add a tags field to tasks — a list of string tags that are:

1. Set at create time: hermes kanban create "Fix auth bug" --tags "owner:backend,night-only"
2. Filterable at list/dispatch time: hermes kanban list --tags "night-only"
3. Visible in task output (JSON and human): included in hermes kanban show
4. Editable: hermes kanban edit t_xxxx --tags "+night-only,-triage" (add/remove tags)

Alternative Approaches Considered

Abuse --skill as tags: Skills are meant to influence worker context, not serve as kanban-level filters. Mixing the two concerns would pollute the skill namespace and confuse dispatch logic.

Structured body prefix: Encoding tags as Tags: run-at-night in the body works today as a manual convention, but requires every consumer (cron, daemon, human) to parse free text. Not robust.

Priority field: Priority is numeric and meant for ordering, not categorisation. Using it to encode meaning (e.g., priority=99 means "night only") is a hack that loses semantics.

Priority

P2 — enables more sophisticated dispatcher and worker patterns without workarounds.