自定义数组写 Zarr 报 int 不可下标：xarray chunks 要逐轴展开

自定义文件数组能放进 Dataset，调用 to_zarr() 却在分块检查里报 TypeError: 'int' object is not subscriptable。堆栈若停在遍历 var_chunks、再取 chunks[:-1] 的位置，应检查数组暴露的 chunks 属性，而不是先改写入目录权限。

xarray 期望数组层的分块描述是“每个轴由哪些块组成”，类型为 tuple[tuple[int, ...], ...]。返回 (2, 5) 只给了二维块的形状，外层遍历拿到整数 2、5，再对整数切片就会失败。正式 v2026.09.0 的分块协议和 Zarr 写入检查仍采用逐轴展开表示，并未承诺接受所有自定义简写。

数组 chunks 和编码 chunks 不是同一个接口

对于形状 (10, 25)、块形状 (2, 5) 的二维数组，规范描述应为：

shape = (10, 25)
chunks = ((2, 2, 2, 2, 2), (5, 5, 5, 5, 5))

每个内层元组的和等于该轴长度，外层长度等于维数。若一个轴长 11、块长 2，末块应描述成 1，不能为了格式统一伪装成总长 12。上面只是协议形状示意，不是给任意数组强行设置一个属性就完成适配。

Zarr encoding 中的 chunks 则可以表达存储块形状。把数组层的简写挪到编码里，不能自动修复自定义数组的协议。xarray 还会结合数组分块与存储分块判断写入是否安全；safe_chunks=False 也不会把整数变成可切片的元组。

修数组适配层，而不只修初次构造

数组类和对应 chunk manager 应返回真实的规范分块信息，并在切片、转置和重分块后同步更新。转置后的外层轴顺序必须跟着变；切走一部分数据后，旧块描述也不能照搬。仅让初始对象通过一次写入，仍可能在后续选择或转置时产生错块。

如果实现本身只是普通 NumPy 数据、并不需要自定义的惰性分块行为，可以在明确允许一次物化且内存足够时，将选定数据转成普通数组后再交给标准写入路径。这会改变加载成本，不适合直接套在大型文件数组上。真正需要惰性处理的后端，应完成数组协议及 chunk manager 的适配。

写到新位置，核对值与布局

验证应覆盖完整数组、非整块切片、转置和末尾短块，逐项检查 shape 与 chunks 的对应关系。写入测试存储时使用独立新目录，读回后比较值、坐标、dtype 和存储分块；能打开元数据还不足以证明块内容正确。

不要在原数据目录反复覆盖试错。自定义实现若仍有不支持的运算，应明确拒绝，而不是沿用旧 chunks 返回一份形状看似正确、实际数据位置已经错位的结果。