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

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

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

AGENTS.md

@@ -0,0 +1,9 @@
+# 项目通用开发规则
+
+- KV模式的迁移目标是由KV管理器及其接线承接原PlayFab相关能力，不只迁个人存档；等级榜、公开资料、好友和匹配是原PlayFab调用的既有功能，不得当作新增产品需求、默认延期或直接转交服务端。先核客户端已有KV能力及等价调用映射；只有明确证实缺少必要能力时，才把具体接口证据集中写入沟通文档。不得反复要求用户确认“是否存KV”、新ID或原邮件流程。已审同合同替换连续实施，确有新合同或架构差异时一次合并评审，避免逐功能送审。
+- 整个迁移流程、所有阶段与批次均只做平移，不限于 M2。全部迁移完成前，仅修改完成迁移所必需的存储、身份和接口接线，保留原业务规则、调用顺序、同步/异步方式、返回值、异常处理和界面流程。不得夹带额外业务修正、优化或代码重构；不得以“更安全”“更合理”或“顺手修复”为由改变原逻辑。
+- 发现原有业务缺陷、代码结构问题或可优化点，统一记录到迁移完成后的待办，不在任何迁移阶段穿插处理。必须等整个迁移流程全部完成后，再由用户另行授权修正；单个阶段完成不构成提前修正的许可。此前方案或评审包含此类扩展时，以此规则及用户最新要求为准。
+- 最终闲置实现清理仅限本次迁移造成且经核实已无消费者的实现，不得借清理重构代码或删除原有有效功能。确有无法保持原流程的迁移障碍，先说明具体差异，不自行改写业务规则或冻结功能。
+- 在满足已确认的功能、正确性和必要安全边界的前提下，优先选择最简单、最直观、最容易维护的实现。抽象应服务于实际调用者；不要为假设中的扩展增加接口、适配器、管理器、状态机或重复保护层。
+- 修改代码前完成相关方案的完整评审，记录裁决和开发边界。评审新增抽象时，说明它解决的具体问题、实际调用点，以及为何复用或小幅修改现有实现不足；无法说明必要性的层次不要引入。
+- 同一事实保持单一来源，同一业务流程避免多重开关和重复状态。迁移中的临时路径须登记，最终通关前恢复或清理；最终代码删除闲置实现，但保留仍在使用的原有功能。