serverCloud条件写入与跨实例一致性确认

项目：Arcane Angler / 秘潮钓师

环境：TapTap Maker UrhoX Lua，Maker MCP 0.0.24，测试版 1.0.19，单人 server_authoritative。

我们正在验证服务端权威存档。当前可见的 serverCloud 能力包括 Get、Set、Add、BatchSet 和 BatchCommit，但在公开文档、EmmyLua 声明和示例中没有找到针对同一持久化键的 CAS、expectedRevision、条件写入或 fencing token。

真实 serverCloud 反证：

我们在独立测试键上先持久化带两条新事务的 rev 2，再用普通 serverCloud:Set 写入从同一基线派生的旧 rev 1。调用被接受，回读确认 revision 回退且两条较新事务丢失；实验后已恢复并复读完整基线，结果为 rev 0 -> 2 -> 1 -> 0。该结果证明持久层接受旧快照，但不推断部署期一定存在两个实例。

项目也已在单个真实服务端实例内验证按玩家 FIFO 队列、同/不同 requestId、超时恢复和断线后继续提交。进程内队列不能约束扩容、发布、重启、空闲回收或故障转移期间可能存在的另一个实例。

请确认 Maker serverCloud 是否提供以下任一能力：

1. CompareAndSwap、SetIfRevision 或等价条件写入；

2. BatchCommit 中声明“仅当当前 revision 等于 N 才提交”的前置条件；

3. 持久层唯一 requestId / 唯一业务事务令牌；

4. 由持久层校验的 lease / fencing token；

5. 平台硬保证的同玩家或全项目单写者模型，并明确新旧实例切换规则。

若存在，请提供 Lua 方法签名、冲突错误码或回调、原子性范围、预览与正式环境差异及配额限制。若当前不支持，也请明确告知。

官方云存档文档提示同一个云存档不允许并发更新；多人在线对战的 expectedValues CAS 作用于房间/玩家自定义属性，并非 Maker serverCloud 持久键。

本次验证只使用四个 aa_g3_* 隔离键和测试资产，不涉及正式玩家存档、完整玩家 ID、昵称或凭据。正式云存档接管在取得可验证合同前保持关闭。