fix(kanban): auto-subscribe on create via CLI and tool

[JonT6]

Summary

Fixes the gap where hermes kanban create (and the kanban_create model tool) advertised "auto-subscribes you to events" but never actually called kb.add_notify_sub(...). Subscriptions only got attached when something explicitly invoked notify-subscribe.

The model tool's _maybe_auto_subscribe was already wired up; this PR brings the bare CLI to parity and documents the behaviour.

Changes

hermes_cli/kanban.py — _cmd_create now resolves a chat binding (explicit --auto-subscribe-* args → HERMES_NOTIFY_* env vars → HERMES_SESSION_* env vars) and calls kb.add_notify_sub after kb.create_task. New flags:

• --no-auto-subscribe — escape hatch for scripted creates
• --auto-subscribe-platform / --auto-subscribe-chat-id / --auto-subscribe-thread-id / --auto-subscribe-user-id — explicit overrides
• --json mode opts out (machine-output callers manage subs explicitly)

When no binding is available the create still succeeds and a stderr note points the operator at hermes kanban notify-subscribe. Two helper functions: _resolve_auto_subscribe_target(args) (pure) and _auto_subscribe_create(...) (side-effecting; logs+swallows on failure).

tests/hermes_cli/test_kanban_core_functionality.py — 6 new tests:

• env binding → sub row written + stdout suffix
• no binding → stderr warning, no sub row
• --no-auto-subscribe overrides env
• explicit --auto-subscribe-* overrides env
• --json skips auto-subscribe (parses output as JSON)
• help text pins the new wording (rejects old misleading claim)

website/docs/user-guide/features/kanban.md — new subsection documenting CLI/tool parity, the opt-out knobs, and the no-binding fallback.

Test coverage

• tests/hermes_cli/test_kanban_core_functionality.py — 172 passed, 1 skipped
• tests/tools/test_kanban_tools.py — 90 passed (auto-subscribe tests on the tool side were already in place)
• tests/hermes_cli/test_kanban_db.py + test_kanban_notify.py + tests/gateway/test_kanban_notifier.py + tests/plugins/test_kanban_dashboard_plugin.py — 102 passed across the cluster
• ruff: clean

Reproduction (post-fix)

HERMES_NOTIFY_PLATFORM=telegram \
HERMES_NOTIFY_CHAT_ID=chat-xyz \
HERMES_NOTIFY_THREAD_ID=7 \
HERMES_NOTIFY_USER_ID=user-1 \
  hermes kanban create "test auto-subscribe" --assignee worker

sqlite3 ~/.hermes/kanban.db \
  "SELECT task_id,platform,chat_id,thread_id,user_id,notifier_profile FROM kanban_notify_subs WHERE task_id='<new_id>'"
# → <new_id>|telegram|chat-xyz|7|user-1|coder

Closes t_d13282da.

[teknium1]

Thanks for tracing the CLI/gateway mismatch. The current CLI path still creates a task without a notification row (hermes_cli/kanban.py:1328-1355), while the gateway handler already subscribes from event.source (gateway/slash_commands.py:450-481), so there is a real CLI-focused gap.

Problems

• The new CLI helper bypasses the existing kanban.auto_subscribe_on_create opt-out: the PR inserts after target resolution (hermes_cli/kanban.py:1120-1132), while the tool checks the gate in tools/kanban_tools.py:999-1001. The documented contract says false requires explicit subscription (website/docs/user-guide/features/kanban.md:511).
• HERMES_NOTIFY_* has no in-tree producer on current main; existing chat-bound terminal subprocesses receive HERMES_SESSION_* through tools/environments/local.py:336-380. The new variables would become a user-facing behavioral env-var surface without an established runtime contract.

Suggested changes

• Honor kanban.auto_subscribe_on_create in the CLI path and test that opt-out.
• Reuse HERMES_SESSION_*; drop the new HERMES_NOTIFY_* mechanism and its docs/repro unless maintainers explicitly want that public interface.
• The tool portion is already present on main (tools/kanban_tools.py:945; f8d8f045facce40351f8a34421764fe514c49c0b), so salvage only the CLI-specific behavior.

Automated hermes-sweeper review.

[teknium1]

Please check kanban.auto_subscribe_on_create before resolving/inserting here. The existing tool honors this config gate (tools/kanban_tools.py:999-1001), and the documented contract says false requires explicit subscription; without it, a chat-bound CLI subprocess ignores the user's opt-out.

[teknium1]

There is no in-tree producer for HERMES_NOTIFY_* on current main. Chat-bound terminal subprocesses already receive HERMES_SESSION_* through tools/environments/local.py::_inject_session_context_env; please avoid adding a new user-facing behavioral HERMES_* convention here.