feat(kanban): let an agent-session CLI create subscribe its origin chat

[Kyzcreig]

hermes kanban create never registers a notify subscription, so a card
created from a terminal inside an agent session finishes silently — the
chat that asked for the work is not watching. The in-process tool path
already handles this (_maybe_auto_subscribe, gated by
kanban.auto_subscribe_on_create); the CLI path never got the equivalent.

Auto-subscribing every CLI call is not the answer — that was #19718 and it
was reverted, correctly: scripts and cron jobs drive the same CLI and have
no delivery channel. So this is two narrower pieces:

1. kanban.cli_auto_subscribe, default false. When enabled, a CLI
   create subscribes the origin chat only if it carries a full gateway
   session identity (HERMES_SESSION_PLATFORM + HERMES_SESSION_CHAT_ID,
   which the gateway exports into terminal subprocesses). Identity is read
   through gateway.session_context.get_session_env, so an explicitly
   cleared session context suppresses a stale os.environ mirror instead
   of subscribing a foreign chat. No identity -> no subscription,
   regardless of the knob, preserving the feat(kanban): auto-subscribe gateway chat on tool-driven kanban_create #19718 rationale.

   The identity resolution + notify-sub write is factored out of
   _maybe_auto_subscribe into subscribe_calling_session(...) so both
   callers share one implementation. require_platform_identity=True (the
   CLI path) additionally skips the TUI HERMES_SESSION_KEY fallback.

2. hermes kanban dispatch now prints one line when spawned cards have
   zero notify subscriptions, regardless of the knob:

   N spawned card(s) have no notify subscription - finishes will be
   silent (kanban.cli_auto_subscribe or notify-subscribe)

   JSON output carries the same fact as spawned_unwatched so stdout stays
   machine-parseable. This is the discoverable half: the operator learns
   about the silence at the moment it is created, not after the cards
   finish. Both paths are best-effort — a notification bookkeeping failure
   never fails a create or a dispatch.

Tests: tests/hermes_cli/test_kanban_cli_auto_subscribe.py (12 cases) —
knob on/off/default, identity present/absent/half, stale-cleared context
rejected, add_notify_sub failure tolerated, warning renders/suppresses/
counts-only-unwatched, JSON field. RED-proven: 4 of the 12 fail on the
parent commit; the other 8 pin the pre-existing default-off behaviour.

---

Why default-false: #19718 auto-subscribed every CLI create and was reverted
for good reason — scripts and cron jobs drive the same CLI and have no delivery
channel. This lands the capability behind an opt-in knob and, separately, makes
the silence visible at dispatch time whether or not the knob is on.

Verification

• pytest tests/hermes_cli/test_kanban_cli_auto_subscribe.py -q -> 12 passed
  (also green across 10 --randomly-seed orderings).
• RED proof: the same file copied onto a detached origin/main worktree ->
  4 failed, 8 passed. The 4 that fail are the new behaviour; the 8 that pass
  pin the pre-existing default-off/no-identity semantics.
• pytest tests/hermes_cli/ -k kanban -p no:randomly -> 177 passed, 7 failed;
  the same 7 fail on unmodified origin/main (pre-existing, order-sensitive:
  test_kanban_write_guard, test_kanban_db, test_kanban_decompose,
  test_kanban_lifecycle_hooks). No new failures attributable to this change.

[alt-glitch]

This was generated by AI during triage.

Related: #50972 also addresses CLI-created kanban notification subscriptions. This PR uses an opt-in setting plus current gateway-session identity, while #50972 takes the broader CLI parity path; maintainer choice is needed.