Question: server-side rejection and atomicity contract for sheets +batch-update in CLI 1.0.82

我们正在核验 @larksuite/cli 1.0.82 的
sheets +batch-update 失败行为。
对应npm gitHead为：
0f29e039d71eb598330f50a60a77b573f9996e0b

希望确认以下通用合成场景：
一个批次先向已有Sheet的单元格写入合成值，
再向不存在的Sheet写入合成值。

请提供适用于该版本的明确契约：

1. 该场景会在CLI本地转换阶段被拒绝，还是由服务端处理后拒绝？
   如何通过可靠的结构化字段区分？

2. 若由服务端拒绝，缺失Sheet对应什么错误标识？
   返回结构如何定位失败子操作？
   请提供官方schema、版本化说明或脱敏响应示例。

3. 该接口支持的严格原子模式如何启用？
   在上述服务端拒绝场景下，是否保证整个批次没有任何操作生效？
   该保证覆盖哪些失败类型，又有哪些例外？

4. CLI最终JSON保留哪些能够支持上述判断的字段？
   哪些字段只是客户端包装生成，不能作为服务端确认？

我们会将启动、凭证、传输、超时和解析错误单独处理；
不会仅凭CLI抛错、revision不变或单元格无变化，
认定已经验证服务端原子性。

感谢提供准确的契约链接或对应实现位置。

Start by reproducing the exact @larksuite/cli 1.0.82 sheets +batch-update scenario at gitHead 0f29e039d71eb598330f50a60a77b573f9996e0b and inspect its structured JSON output. Done means documenting the server-versus-client failure distinction, missing-Sheet error and failed sub-operation fields, atomic-mode behavior and exceptions, with an official schema, versioned reference, or redacted response example.