feat(lark): 支持接收飞书图片消息

[kindaQ]

这个 PR 做了什么？

让绑定到 Agent 的飞书机器人能够接收用户发送的图片，并将图片作为 Multica 附件传递给后续任务。修复前，飞书图片只会被展开成 [Image] 占位符，图片二进制不会下载、落库，Agent 因而无法读取图片内容。

思考路径

1. 飞书入站消息解析目前只保留纯文本结果，图片会退化为占位符。
2. 图片既可能是顶层 image 消息，也可能嵌在带文字的 post 富文本消息中，因此需要保留原始消息内容并统一提取 image_key。
3. 在聊天消息写入前，通过飞书消息资源接口下载图片，校验实际 MIME 类型，再交给现有对象存储。
4. 图片附件与用户聊天消息在同一事务中建立关联，确保后续任务可以获得附件元数据并通过附件下载命令读取图片。
5. 使用稳定的对象键处理飞书事件重投，避免重复投递持续产生孤立文件。

关联 Issue

暂无关联 Issue。

变更类型

• Bug 修复（不破坏兼容性的行为修复）
• 新功能（不破坏兼容性的功能增加）
• 重构 / 代码改进（无行为变化）
• 文档更新
• 测试（新增或改进测试覆盖）
• CI / 基础设施

具体改动

• server/internal/integrations/lark/ws_frame_decoder.go
  • 保留飞书消息的原始 content，供附件管线解析。
  • 顶层图片消息继续生成稳定的 [Image] 文本占位，同时标记消息类型为图片。
• server/internal/integrations/lark/inbound_media.go
  • 支持提取顶层 image 和 post 富文本中的一个或多个图片键。
  • 通过飞书消息资源接口下载图片，并对下载内容进行 MIME 嗅探和图片格式白名单校验。
  • 将图片写入现有对象存储，使用稳定对象键兼容事件重投。
• server/internal/integrations/lark/http_client.go
  • 新增飞书消息资源下载能力，并限制响应体大小。
• server/internal/integrations/lark/feishu_resolvers.go
  • 在聊天消息写入前完成图片下载，并把附件引用传入共享聊天会话管线。
• server/internal/integrations/channel/engine/session.go
  • 在用户消息事务中创建附件记录、关联聊天消息与任务，并把附件信息加入任务提示。
• server/cmd/server/router.go
  • 将飞书媒体服务接入现有飞书入站消息处理链路。
• 补充顶层图片、富文本图片、资源下载、内容类型校验、附件落库和消息映射测试。

如何测试

1. 运行飞书集成和共享消息管线测试：
   go test ./internal/integrations/lark ./internal/integrations/channel/... ./internal/integrations/slack
2. 运行全量 Go 编译检查：
   go test ./... -run ^
3. 本地启动服务并绑定飞书机器人，分别发送：
   • 单独一张图片；
   • 图片加文字的富文本消息；
   • 包含多张图片的富文本消息。
4. 确认聊天消息保留文字内容，附件记录与消息及任务关联，Agent 可以下载并读取图片。

本地自动化测试和全量 Go 编译检查均已通过。

风险与边界

• 当前只接入图片；文件、音频和视频仍保留原有占位符行为。
• 图片下载失败时，消息处理会返回错误并交由现有飞书事件重试机制处理。
• 下载响应有大小限制，且会根据实际文件内容校验图片 MIME 类型，避免仅信任响应头。
• 多图片按消息内顺序处理；重复的图片键会去重。

检查清单

• 已包含从项目上下文到本次改动的思考路径
• 已在本地运行测试并通过
• 已在适用位置新增或更新测试
• UI 截图：不适用，本次不涉及 UI
• 文档更新：不适用，本次未增加配置项或用户操作入口
• Landing 与运行时文档同步：不适用，本次未新增运行时、编码工具或 UI 标签页
• 中文产品文案规范检查：不适用，本次没有修改产品文案
• 已考虑并记录风险
• 会在请求合并前处理所有审查意见

AI 使用说明

使用的 AI 工具： Codex

方式： 用于分析飞书入站消息链路、实现图片下载与附件关联、补充测试，并根据测试结果修正图片加文字时使用 post 消息类型的兼容问题。

截图

不适用，本次为后端消息与附件管线改动。

[vercel]

@kindaQ is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.

[multica-eve]

Hi @kindaQ, thank you for putting this together and for the thorough test coverage.

We confirmed that inbound Feishu/Lark image attachments are already being implemented in #5580. That PR covers the same core behavior here, including standalone and rich-text images, and also extends it to videos and a durable asynchronous media-ingestion lifecycle.

To avoid maintaining two overlapping implementations, we are going to continue this work in #5580 and close this PR as superseded. We really appreciate your contribution and the care you put into it. Please feel free to follow #5580 for progress. Thanks again!