[Bug][sheets] +table-put --styles 写入 5,890 个单元格约 62 秒后返回 HTTP 502

问题概述

生产用户任务中，lark-cli sheets +table-put --sheets ... --styles ... 写入 588 行数据 + 1 行表头、10 列，共 5,890 个单元格，单个 set_cell_range 请求约 1.36 MB，约 62.4 秒后返回 HTTP 502 Bad Gateway。

后续改成 75 行分批后，部分批次仍出现 502（包括 75 行和尾批 63 行）；因此不能简单认定“超过某个行数必然失败”或“拆批即可解决”。原任务在多次重试和调整批次后总耗时约 18.5 分钟。

这是已观测到的生产故障，根因尚未确认。 希望协助定位超时/502 所在层，以及明确结果不确定时的安全恢复方式；暂不将根因归于 CLI、网关或 Sheets 服务中的任何一方。

环境与生产证据

• 生产 CLI：1.0.92，通过失败请求的 User-Agent: lark-cli/1.0.92 确认。
• 身份：user。
• 生产路径经过 Agent 沙箱代理。
• 发生时间：2026-09-18 02:59:16–03:00:19（UTC+8）。
• 失败请求 LogID：021789671556855fdbddc530010014e120c3c0ec4000032338be2。
• 请求：POST /open-apis/sheet_ai/v2/spreadsheets/<redacted>/tools/invoke_write。
• 操作：set_cell_range，范围 A1:J589。
• Content-Length: 1361278；代理侧记录耗时约 62.425 秒，返回 HTTP 502；代理授权判定为允许。
• CLI 退出码 4，错误字段为 type=network、subtype=server_error、code=502、retryable=true。

脱敏错误摘要（message 中省略了 HTML 响应体，仅保留其标题）：

{
  "ok": false,
  "identity": "user",
  "error": {
    "type": "network",
    "subtype": "server_error",
    "code": 502,
    "message": "table-put failed on <redacted>: writing sheet \"<redacted>\" failed: writing rows 1-589: HTTP 502: ...502 Bad Gateway...",
    "hint": "no sheets were written; fix the cause and retry",
    "log_id": "021789671556855fdbddc530010014e120c3c0ec4000032338be2",
    "retryable": true
  }
}

这些日志能确认经过代理后收到了 502，不能确认是哪个网关/服务生成了 502，也不能仅凭 CLI 的 hint 确认服务端完全没有落表。

希望维护者协助确认

1. 能否用上述时间和请求 LogID 确认约 62 秒的 502 来自哪一层？invoke_write 是否存在相关超时/负载限制，客户端应如何识别？
2. 对 HTTP 502 / 超时这种写入结果不确定的情况，no sheets were written 的依据是什么？是否可以区分“确认没有生效”和“结果未知”，给出回读后仅补写未完成范围的指导？是否有可查询的请求结果标识或幂等机制？
3. 能否提供可配置的单批行数/单元格数/序列化字节预算，或在失败时给出有界的缩批恢复方案，同时避免重写已成功部分？这里不预设固定 75 行一定更合理。
4. lark-sheets 的“一步带样式”指导能否补充大数据/多格式操作场景的边界，并与 CLI 的实际拆批和恢复行为一致？

关联：#2720（失败时的原子性及落表结果契约）、#2140（Skill 与 CLI 指引一致性）。本 issue 重点是生产 invoke_write 的 502 及恢复语义，不将其它已修复的样式问题视为同一根因。

Start by reproducing the lark-cli sheets +table-put --styles request shape and reviewing the reported invoke_write request, timing, HTTP 502 response, and LogID. Done means identifying which layer produced the failure and documenting whether the write result is confirmed or unknown, along with a safe recovery procedure that avoids rewriting successful ranges.