feat(kanban): auto-subscribe origin conversation on kanban_create tool

[TheoLong]

What

The kanban_create tool (used by orchestrator + worker agents) now auto-subscribes the originating conversation to terminal notifications, with parent-inheritance on worker fan-out. The originating thread becomes the durable manager of the whole subtree — no cron, no skill discipline, no manual `/kanban notify-subscribe`.

Why

The notify infrastructure already exists (`kanban_notify_subs` table, gateway notifier polling every 5s, /kanban slash command and dashboard toggle both wire it up). What was missing: the tool path. So tasks spawned by an agent inside a Discord thread had no way to phone home unless someone manually subscribed or ran a per-thread cron.

How

In `tools/kanban_tools.py::_handle_create`, after `kb.create_task(...)`, call `_auto_subscribe_origin(kb, conn, new_tid)`. Two-step resolution:

1. Live gateway session. `gateway.session_context.get_session_env()` reads HERMES_SESSION_PLATFORM / CHAT_ID / THREAD_ID from the contextvars set per-task by the gateway. When present, that's the exact (platform, chat, thread) the user is in — Discord thread, Telegram topic, Slack thread, etc.
2. Parent task inheritance. When the creator is a kanban worker (`HERMES_KANBAN_TASK` set) with no live session, copy the parent task's subscriptions. This keeps the origin attached to every descendant when fan-out goes through multiple worker hops.

Failures in auto-subscribe never break task creation (logged at DEBUG). The `UNIQUE(task, platform, chat, thread)` constraint on `kanban_notify_subs` makes the operation idempotent.

Tests

`tests/tools/test_kanban_tools.py` — 6 new cases:

• Live Discord thread → subscribed
• Channel-root message (no thread) → subscribed with empty thread_id
• No origin signal at all → no sub, silent (correct)
• Worker fan-out inherits parent's subs
• Live session wins over parent inheritance
• Duplicate auto-subscribe is idempotent

All 64 `test_kanban_tools.py` + 16 notifier/notify-sub tests pass.

Out of scope

• Per-task opt-out flag on `kanban_create` (e.g. `notify_origin=False` for cards a noisy orchestrator wants silent). Easy to add later if fan-out noise becomes real.
• Rolling fan-out children's events up into a parent summary instead of N separate pings. Same — additive when needed.

[alt-glitch]

This re-implements the auto-subscribe feature that was merged in #19718, then reverted in #19721. The replacement approach merged in #19864 uses explicit per-platform dashboard toggles instead of auto-subscribe.

Multiple competing PRs already exist for re-implementing the old approach: #25195 (open, primary), #24307 (open), #21523 (open).

12 files changed across kanban, discord, CLI, gateway — large blast radius for a feature that was intentionally reverted.

[impara]

I checked this against a live Telegram/orchestrator Kanban flow and can confirm the user-visible behavior described here.

Observed situation:

• The user sends a natural-language request to the orchestrator Telegram gateway.
• The orchestrator creates a Kanban task through the kanban_create tool path, not through the /kanban create ... slash-command path.
• The task is created and dispatched normally.
• The worker can complete the task and write the normal Kanban completion event.
• The originating Telegram chat does not receive a completion reply/ping.

Local evidence from the live instance:

• gateway/run.py has the Kanban notifier watcher that sends terminal events from kanban_notify_subs.
• hermes_cli/kanban_db.py writes the completed task event with the handoff summary when a task completes.
• /kanban create ... in the gateway path auto-subscribes the originating chat by adding a kanban_notify_subs row.
• tools/kanban_tools.py::_handle_create creates tasks for the kanban_create tool path, but on this checkout it does not add a notify subscription.
• The local board database showed kanban_notify_subs count 0 after a natural-language orchestrator-created task was spawned.
• The task event log for that task contained created, claimed, and spawned events, but no subscription row existed for the Telegram origin, so there was no route for the notifier to deliver the eventual terminal event.

User-facing impact:

A Telegram user can ask the orchestrator in natural language to dispatch work, see the orchestrator accept/create the task, and then receive no completion notification when the Kanban worker finishes. From the user's perspective, the work appears to disappear unless they manually check the board or ask the orchestrator for status later.

This is distinct from the slash-command path: tasks created with /kanban create ... are auto-subscribed to the originating gateway chat and are expected to send terminal-event pings back.

[teknium1]

Thanks @TheoLong — closing this one. 620 LOC across 12 files including gateway/discord, title_generator, and cli.py is cross-cutting design territory. The auto-subscribe-on-kanban_create direction is similar to #24307 (closed) which re-introduces a previously reverted feature. We have gateway-create auto-subscribe today; if the gap from current behavior is concrete, please open an issue. Appreciate the work.