feat(dingtalk): support outbound file delivery

[qqqys]

What this PR does

This adds native outbound file delivery to the DingTalk channel. When the agent emits an explicit local-file marker in its final response, the channel validates a file under the workspace or system temporary directory, uploads it through DingTalk's media API, and sends a native file attachment for session replies and proactive group or direct messages. It caps each response at five files and each file at 20 MB.

Streaming, terminal cards, cancellation, and text fallbacks now suppress file markers and local paths. File upload and delivery failures produce an explicit failure notice instead of a false success claim. The outbound image path now shares the same local-file validation, media upload, marker parsing, and truncation safety primitives.

Why it's needed

The DingTalk channel could return text and images but could not deliver generated reports, archives, source files, or other non-image artifacts as downloadable attachments. Users could receive a textual claim that a file had been sent without receiving a native DingTalk file message.

Reviewer Test Plan

How to verify

Configure a DingTalk Stream robot with streaming enabled, mention the bot in a group, and ask it to send an existing file from the current workspace rather than pasting its contents. Expect the response card to omit the internal marker and local path, followed by a native DingTalk file card whose download opens the original file. Also verify that an outside-workspace path, oversized file, empty file, or sixth file produces a bounded failure notice without an attachment or path disclosure.

Evidence (Before & After)

Before: the channel could describe a file but did not deliver a downloadable non-image attachment.

After: a live macOS DingTalk Stream run delivered the workspace package.json as a native 9.6 KB file card, and the downloaded file opened successfully. Automated terminal-card coverage verifies that the final content, copy text, and rendered block contain neither File pending nor the internal file marker or local path.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

Local source checkout with a DingTalk Stream robot and interactive status cards enabled.

Risk & Scope

• Main risk or tradeoff: outbound files use DingTalk's upload and robot-message APIs, so delivery depends on the app's permissions and DingTalk's availability; credentials remain scoped to their matching official API boundary.
• Not validated / out of scope: inbound file handling and file-marker prompting in block-streaming mode; CI should provide Windows and Linux coverage.
• Breaking changes / migration notes: none.

Linked Issues

Fixes #9166

中文说明

此 PR 的作用

此 PR 为钉钉 channel 增加原生的出站文件发送能力。当 Agent 在最终回复中输出明确的本地文件标记时，channel 会校验工作区或系统临时目录内的文件，通过钉钉媒体接口上传，并在会话回复、主动群聊消息或主动私聊消息中发送原生文件附件。每次回复最多发送五个文件，每个文件最大 20 MB。

流式输出、终态卡片、取消流程和文本降级路径现在都会隐藏文件标记和本地路径。文件上传或发送失败时会给出明确的失败提示，不会错误宣称发送成功。出站图片链路现在也复用了相同的本地文件校验、媒体上传、标记解析和安全截断逻辑。

为什么需要

钉钉 channel 之前可以返回文本和图片，但无法把生成的报告、压缩包、源文件或其他非图片产物作为可下载附件发送。用户可能看到“文件已发送”的文字，却收不到钉钉原生文件消息。

Reviewer Test Plan

如何验证

配置一个启用流式输出的钉钉 Stream 机器人，在群里 @机器人并要求它发送当前工作区中已经存在的文件，而不是粘贴文件内容。预期回复卡片不展示内部标记和本地路径，随后出现钉钉原生文件卡片，下载后可以打开原文件。还应验证工作区外路径、超大文件、空文件或第六个文件只产生受控的失败提示，不发送附件，也不泄露路径。

证据（修改前与修改后）

修改前：channel 可以描述文件，但不会发送可下载的非图片附件。

修改后：在 macOS 上通过真实钉钉 Stream 验证，工作区的 package.json 被发送为 9.6 KB 的钉钉原生文件卡片，下载后可以正常打开。终态卡片的自动化测试进一步确认最终正文、复制文本和渲染块均不包含 File pending、内部文件标记或本地路径。

测试平台

OS	状态
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境（可选）

本地源码检出，配置钉钉 Stream 机器人并启用交互式状态卡片。

风险与范围

• 主要风险或权衡：出站文件依赖钉钉上传和机器人消息接口，因此发送结果取决于应用权限和钉钉服务可用性；凭据只会发送到与其匹配的钉钉官方 API 边界。
• 未验证或不在范围内：入站文件处理，以及 block-streaming 模式下的文件标记提示；Windows 和 Linux 覆盖由 CI 验证。
• 破坏性变更或迁移说明：无。

关联 Issue

Fixes #9166