Summary

Fix gateway /kanban auto-subscribe behavior when the command uses an explicit board override.

Before this change, a gateway command like:

/kanban --board projx create "board scoped task"

would create the task successfully, but the gateway would fail to auto-subscribe the originating chat/thread to task notifications.

Problem

The gateway handler detected create commands by checking only the first token after /kanban. That works for /kanban create ..., but fails for /kanban --board <slug> create ... because the first token is --board, not create.

There was a second consistency issue in the same path: even if create detection had worked, the auto-subscribe write used an implicit kanban connection instead of the explicit board override, which could route the subscription to the wrong board DB.

Root Cause

In gateway/run.py:

• create detection used a naive first-token check
• the follow-up add_notify_sub(...) path opened kanban_db.connect() without passing the explicit board context

Fix

• Parse /kanban arguments with shlex
• Skip leading --board / --board=<slug> options when detecting the actual subcommand
• Treat the command as create when the first non-board token is create
• Reuse the resolved board override when opening the DB for auto-subscribe

Why this is safe

This is a narrow gateway-only fix:

• no schema changes
• no new Kanban behavior
• no refactor outside the existing /kanban handler
• no changes to notifier semantics beyond restoring expected behavior for explicit-board creates

Tests

Added a regression test covering:

• /kanban --board <slug> create ... through the gateway handler
• successful auto-subscribe message in the command output
• notify subscription written to the explicit board
• no stray subscription written to the default board

Validated together with existing Kanban notify and multi-board tests.