fix(kanban): make creator wake turns graph-safe

[yinkev]

Summary

Harden Kanban creator-session wake-ups so a terminal event does not look like a fresh decomposition request:

• carry the worker's human-facing completion handoff into the synthetic wake turn
• identify the turn as an automatic task-status notification
• instruct the resumed agent to inspect the existing board before creating follow-up work and never recreate tasks/graphs that already exist
• consolidate kanban.auto_subscribe_on_create into the effective DEFAULT_CONFIG["kanban"] block so the documented opt-out validates as a known config key
• clarify in English and zh-Hans docs that:
  • auto_decompose gates only the built-in Triage decomposer
  • creator wake-ups are independently controlled by auto_subscribe_on_create
  • built-in decomposition stamps created_by=auto-decomposer, while profile-created work stamps the profile name

Root cause for #70752

Current main has one built-in automatic decomposition producer: the gateway Triage watcher. It re-reads kanban.auto_decompose every tick, acts only on Triage tasks, and creates children with created_by=auto-decomposer.

The report's duplicate tasks were stamped created_by=orchestrator and appeared one notifier interval after the root completed. That provenance matches the independent creator-wake path: an auto-subscribed terminal event resumes the originating orchestrator session with a synthetic user turn, and that profile can call kanban_create for follow-up work. The old wake carried only task ID/title/status and the open-ended instruction “decide the next step”; it omitted the worker result that would tell the resumed model the pipeline already existed.

This PR preserves intended event-driven orchestration. It does not fuse auto_decompose and notification controls or prohibit legitimate follow-up creation.

Addresses #70752.

Verification

• targeted Kanban notifier, auto-decompose, auto-subscribe, config, and i18n suites: 281 passed
• ruff check on touched Python files
• py_compile on touched Python files
• all 17 locale catalogs contain matching wake keys/placeholders
• DEFAULT_CONFIG contains one effective kanban block and recognizes kanban.auto_subscribe_on_create
• git diff --check

[alt-glitch]

This was generated by AI during triage.

Related to #66703: both change creator-wake policy, but this PR preserves automatic wakes and constrains their synthetic turn while #66703 makes wakes explicit and thread-isolated. Maintainer decision needed on the intended delivery-versus-conversational contract.

[yinkev]

Clarifying the relationship to #66703: these changes are orthogonal, not competing implementations of the same mechanism.

#66703 proposes a new enablement policy (wake_creator_session: false by default) inside a much broader +582/-9 session-ownership/handoff/footer PR. That PR is currently blocked on regressions in the intentional no-thread handoff fallback and an unconditional SessionDB query. Its wake-policy direction therefore still needs a separate maintainer decision.

#71100 deliberately does not change whether creator wakes are enabled. It preserves current main's established auto_subscribe_on_create contract and hardens the payload of any wake that does occur:

• include the worker's terminal handoff/result;
• identify it as a notification rather than a decomposition command;
• require board inspection and prohibit recreating existing tasks/graphs;
• restore the existing opt-out key to the effective config schema.

Those properties remain correct if maintainers later make wakes opt-in, restrict them to threads, or keep today's default. Even under #66703's proposed policy, an explicitly enabled wake still needs this context and idempotency guidance.