feat(upserver): 保存M2客户端KV迁移至本人统计写检查点

保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。
保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。

验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。
包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。

CodexOutput/upserver/B3BatchMigration/M2/M2-CP3A独立实施复核.md

@@ -0,0 +1,74 @@
+# M2 CP3A独立实施复核
+
+日期：2026-09-29。审查者：ZCode会话（M2全链审查者）。本轮只读＋hash重算＋源码核对＋**独立复跑**；未修改生产/测试源码/共享文档。
+
+## 受审hash核对
+
+`M2-CP3A-C11交付hash.json`：**10/10全部一致**；清单SHA256 `2E3E1EB14807709E…`与交付记录吻合。
+
+## 总裁决
+
+**通过（限定）。CP3A可限定关闭**（主会话裁决后）——两项限制保留：①真实Player编译未验（CP2A连带），②Editor直开真实启动验收未运行。
+
+## 独立复跑
+
+| 项目 | 交付记录 | 本复跑 | 退出码 |
+|---|---|---|---|
+| KVGameLoadTests | 89组/1962断言 | **89组/1964断言/0失败**（+2断言为CP3A新增覆盖） | 0 |
+| B02RouteTests | — | **1组/61断言/0失败** | 0 |
+
+## 逐项审查
+
+### 1. 原handle/epoch/三原实例一致性：确认
+
+交付§1.1：GameLoaded→同epoch核验→**现有**Setting/Club/Notification原实例预检→一次绑定——与CP3A方案§3.2一致。交付§1.2部分失败沿Coordinator撤销，同进程不重绑——与方案§3.2"部分失败撤销＋拒绝重登"一致。
+
+### 2. 未绑定时PF失败关闭：确认
+
+交付§1.2：Setting/Club正式KV无句柄期间对两键失败关闭，不触发PF——与方案§3.1"无句柄实例报可诊断错误，不调PlayFabMgr.Instance"一致。
+
+### 3. 部分失败撤销与重登限制：确认
+
+合成用例28断言覆盖部分绑定撤销＋跨epoch拒绝——V05场景覆盖。
+
+### 4. 通知在途与B01语义：确认
+
+交付§1.2：通知保持已初始化原实例、绑定前检查初始化/授权在途、恢复后核固定Setting——与方案§3.2/3.3一致。两键B01语义（缺键/已存在值/Accepted/不确定/陈旧Owner）保持。
+
+### 5. Editor直开PF补审实现：确认符合单文件边界
+
+交付§1.3：`InternalEditorBoost.Init()`在服务注册前取冻结选择→缺选仅精确`playfab`注册→已有沿用→KV/未知拒绝——与批准补审方案精确一致。§3.4纯Editor测试改用显式PF测试构造——合理（不依赖启动容器）。
+
+### 6. 闲置实现检查：确认无闲置
+
+CP1三接口（TryAcquireGameHandle/TryGetCurrentGameHandle/LoadForGameAsync）在UserService.KVLoad.cs中有真实消费者（本审查grep确认）——无闲置。CP3A新增的绑定方法在UserService.KVLoad.cs中有真实调用——无闲置。
+
+### 7. 测试证据可证明什么与未验证限制
+
+**已证明**（合成/Editor层）：
+- 未绑定拒绝、同handle幂等、通知在途预检、部分绑定撤销、跨epoch拒绝（28断言）
+- 全量加载89组含CP3A场景
+- 旧B01/路由/M14/31模块回归
+- Unity Editor编译0错误
+- LoginStage不进FishingStage（静态核）
+- 正式101/102请求0
+
+**未证明（如实保留）**：
+- **真实Player脚本编译**——CLI Loop Restricted拒绝
+- **Editor直开真实启动**——`InternalEditorBoost`的真实Boost()调用未运行（仅源码＋编译＋受影响合成回归）
+
+### 8. Editor直开验收是否可凭当前证据限定接受
+
+**可以限定接受。** 理由：
+- 该补审改动仅SubBoostrap.cs的Init()内注册一段冻结选择——逻辑简单（条件注册/不覆盖/拒绝KV）
+- 已有受影响合成回归（两处解码测试改用显式PF构造后通过）验证了Club构造路径
+- Editor直开是**开发调试路径**非正式运行路径——风险远低于正式Player构建
+- 如需补验收，建议方法：在Unity CLI Loop Editor中用`execute-dynamic-code`直接调用`InternalEditorBoost.Boost()`并检查容器中PlayerKVRuntimeSelection存在——**无需Play/打包/不污染正常容器**（Boost自身创建独立容器上下文）
+
+## P3
+
+- **P3-1**：建议后续CP2B/CP3实施时一次性补Editor直开Boost()验证（方法如上），连同Player编译一起关闭CP2A/CP3A的Player验证缺口。
+
+## 结论
+
+**通过CP3A限定关闭。** 两项限制保留（Player编译/直开验收）由后续统一关闭。CP2B首场景为下一步。