feat(task): 任务描述支持图片 / 图文混排（当前只能读到 [Image] 占位，回写会静默丢图）

背景

飞书任务的描述在客户端里支持粘贴图片，但通过 CLI / OpenAPI 完全无法处理：读不到、写不了，而且会被静默破坏。

现状

1) 读：图片只呈现为纯文本占位 [Image]，v1 / v2 都一样

$ lark-cli api GET /open-apis/task/v2/tasks/<guid> --as user
"description": "改动：\n- xxx\n- yyy\n[Image]"

$ lark-cli api GET /open-apis/task/v1/tasks/<guid> --as user
"rich_description": "改动：\n- xxx\n- yyy\n[Image]"

v1 的 rich_description 与 v2 的 description 返回值完全相同，都拿不到图片的任何可寻址信息（没有 file_token、没有 URL）。

2) 写：无法写入图片

task tasks create / patch 的 description 是纯文本，没有任何图片语法；v1 rich_description 的 Markdown 模块也只支持 @人 和链接。要往描述里放图，目前只能人工在客户端里粘贴。

3) 最严重：读-改-写会静默删掉图片

lark-cli api PATCH /open-apis/task/v2/tasks/<guid> \
  --data '{"task":{"description":"...修改后的文本..."},"update_fields":["description"]}'

因为读出来的 [Image] 只是三个字符，回写时它就变成了字面文本，原图片被永久删除，全程没有任何警告。

对 AI Agent 场景尤其危险：Agent 看到的只有 [Image]，既无从判断这里原本有内容，也没有任何手段把它重建回来。目前唯一安全的做法是「发现描述里有 [Image] 就完全不要用 API 改描述」，这对自动化很不友好。

期望

1. description 支持图文混排：提供图片上传 + 在描述中引用的能力（类似 im images / drive 的 file_token 机制），让 CLI 也能写出带图的任务描述
2. 读取返回可寻址标识：把 [Image] 换成带 token/URL 的结构化表示，至少让调用方能在回写时原样带回，不丢数据
3. 兜底保护：在 2 落地前，若原 description 含 [Image] 占位而 patch 内容不含，CLI 应给出警告或要求显式 --force，避免静默数据丢失

其中 3 成本最低，能立刻消除数据丢失风险；1 是真正想要的能力。

环境

• lark-cli version: 1.0.85
• 相关命令：task tasks create / task tasks patch / api GET|PATCH /open-apis/task/v2/tasks/{guid}

Start by tracing the task tasks create and patch commands, then compare their description handling with the task v1/v2 GET and PATCH API examples in the issue. Determine which of the requested paths is feasible—structured image support, addressable reads, or the interim loss warning—and define completion around preserving images or preventing silent loss with explicit user feedback.