feat(kanban): "session_event" delivery mode for kanban task subscriptions

[loicnico96]

What does this PR do?

Adds an alternative delivery mode to Kanban task subscriptions, which delivers a synthetic event message to the gateway agent session (by gateway session key). This lets the agent act on Kanban events, without requiring polling or CRON-based monitoring.

Adds a parameter to kanban task creation tool and CLI to bind one such subscription immediately upon creation.

The goal is to replace polling:

• Can continue chatting independently (compared to tool-based polling blocking the turn) AND get in-chat agent messages (compared to cron-based polling)
• Can react in seconds rather than minutes for cron jobs
• Can get better summary of task output/blocker (compared to basic notifications usually showing truncated output)
• Can followup on blocker directly (the main session keeps the high-level context of the workflow, don't need to re-explain)
• Can teach the agent to auto-unblock or perform side-effects on completion, with natural wording, on-the-fly (compared to scripts)

Willing to update any naming / api as preferred by maintainers

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

Extend the existing Kanban notifications with a secondary "delivery mode".

The default mode is "notification" (send a notification to the subscribed thread/channel, user-only), matching the current behavior.

The new mode is "session_event", which sends both a notification and enqueues a new turn to the session itself. The message includes explicit wording indicating it is synthetic, and includes minimal guidance for the agent to react. The user may explain / teach their agents how to react to such messages, through skills or direct instructions. A simple example would be deciding whether to automatically unblock a worker or not; or to generate more complete / tailored summary of the progress.

I have explicitly NOT modified skills in this PR so as not to make it opinionated. It only provides the infrastructure, which users can opt-in immediately by updating skills and instructions on their side.

The synthetic events are queued so they behave as non-steering/interrupting watcher handbacks rather than new user instructions, though the gateway does not expose a true barrier between synthetic and user messages (and the PR is big enough without diving into that). The user can continue chatting normally with the agent, for example by changing the guidelines on how to react to future events.

The system is explicitly built on top of existing notification subscriptions, in order to reuse the same commands and internal infrastructure (notifier loop, event cursor, auto-unsub on completion/archival, auto-deletion on task cleanup). The primary key is unchanged, so a same channel only supports 1 delivery mode (but the mode can be switched). Any number of subscriptions of same or different modes can co-exist, although multiple agent watchers would be obviously discouraged.

How to Test

Ask an agent to create a task and watch it. Tell the agent how to react to messages. Observe the agent responding.

This works with arbitrary indirection as long as instructions are precise about forwarding the session key. You can ask the agent to call a subagent to create a task which creates multiple tasks with the correct subscriptions - it will all go back to the original channel.

Fast flow to test is: "Create a task with --watcher-session-key that waits for 20 seconds, then completes with a random integer as output. When you receive a completion event, show me the picked number in hexadecimal. Do not poll or monitor the task in any other way."

Queue semantics can be live-tested with something like: "Wait 2 minutes in 10-second intervals. Use a separate tool call for each interval, without ending the turn." The notification appears between tool calls, but the agent only takes the synthetic turn once idle again.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Ubuntu 24, including DB migrations

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Basic example:

Example live-steering the agent's reaction:

[teknium1]

Thanks for the explicit session-key design. Main now has overlapping creator wakeups from c69643026, but it documents that DM/thread origins cannot be reconstructed and may wake a fresh group session (gateway/kanban_watchers.py:517-533); an exact bound key remains useful.

Problems

• In PR commit b7aa915d47cd, _deliver_kanban_session_event logs a failed synthetic enqueue and still returns success. The notifier then advances its cursor, so the bound-session handback is lost rather than retried.
• The notifier moved out of gateway/run.py into GatewayKanbanWatchersMixin (gateway/kanban_watchers.py:112), and current main routes adapters through the profile authorization chokepoint. This needs a targeted port, not a direct transplant.

Suggested changes

• Port the delivery mode into gateway/kanban_watchers.py, preserving current profile-aware adapter resolution.
• Make a failed session enqueue retryable, and add DM/thread plus active-session queue-path coverage.

This is an automated hermes-sweeper review.