feat(channels): add DingTalk Workspace channel - #9049

What this PR does

Adds a built-in DingTalk Workspace channel that uses an existing authenticated DWS CLI profile. It supports direct messages, @mentions and configured ambient groups, DingTalk document-mention notifications, native todo changes, source-scoped sessions, final replies to the originating message, document comment, or todo, and a temporary 暗中观察 reaction while accepted message tasks run.

The channel reuses the shared sender and group policy model, defaults managed instances to pairing, pins one DWS profile for the channel lifetime, filters the DWS subprocess environment, persists delivery targets, processed-message cursors, and todo fingerprints, suppresses outbound echoes and duplicate pairing notifications, and exposes the channel through CLI, daemon/Web Shell management, build, release, and documentation paths. Native todo watching is opt-in, baselines existing pending todos, polls executor assignments every 30 seconds, and writes the final response back as a todo comment without reacting to its own comment metadata.

Why it's needed

The existing DingTalk channel is intentionally a dedicated application-bot adapter. Users who already authenticate DWS need a separate account-backed channel, analogous to the GitHub channel, so Qwen Code can receive workspace events and respond using the existing DWS login without requiring a bot application.

Reviewer Test Plan

How to verify

1. Install DWS CLI 1.0.57 or newer, authenticate one profile, configure a type: "dws" channel with pairing policies, and start it with qwen channel start <name>.
2. Send a direct message from another DingTalk account. Confirm one pairing notification is produced, approve it, then confirm subsequent messages receive 暗中观察 while the task runs and get one final reply.
3. Send ordinary messages from an unapproved automated account. Confirm they are rejected without repeated pairing notifications or agent execution.
4. In a DingTalk document, add a comment that @mentions the authenticated account and enable the notification option. Confirm the channel reads the referenced document and posts the final answer under the original comment; disabling the notification should not create a task.
5. Configure a concrete group or "*" with requireMention: false and verify ordinary group messages obey both group and sender policy gates.
6. Set watchTodos: true, start the channel once to establish a baseline, then assign a new native todo to the authenticated account. Confirm it runs once and the final response appears as a todo comment; changing only comments or modification timestamps must not start another task.

Evidence (Before & After)

Before: Qwen Code had no built-in channel for an existing DWS login; only the dedicated DingTalk bot adapter was available.

After: A locally authenticated DWS profile can start the channel, receive direct/group/document notifications, poll opted-in native todo changes, show a working reaction for messages, and route the final response back to the originating surface. Live validation also confirmed that repeated automated messages produce one pairing notification per pending request instead of an outbound loop.

Tested on

Environment (optional)

macOS, Node.js 22+, DWS CLI 1.0.57, local TypeScript development checkout.

Risk & Scope

• Main risk or tradeoff: Document mentions currently depend on the DWS direct-message notification card; the five-second incremental history fallback covers cards omitted by the real-time stream. DWS 1.0.57 does not expose native todo events, so todo assignments and actionable changes are polled every 30 seconds.
• Not validated / out of scope: Windows and Linux live DWS authentication, DingTalk bot behavior, document comments that do not generate an account notification, and todo comment-only changes or completion events.
• Breaking changes / migration notes: None. The existing dingtalk channel remains separate and unchanged.

Linked Issues

N/A