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

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

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

CodexOutput/upserver/B3BatchMigration/M2/M2-C2c差异方案业务流程保留补充-2026-09-30.md

@@ -0,0 +1,21 @@
+# C2c 差异方案：原业务流程保留补充（待合并审查）
+
+用户要求：修改不得破坏原主要业务逻辑与工作流程。本补充与 2026-09-29 三文件差异方案合并一次审查；原文与 hash 保留。本次不改生产代码。
+
+## 核对结论
+
+两个 KVFishing 验证文件只拟修离线 fixture 注册与依赖注入，禁止改变正式钓鱼/发奖/扣费逻辑或弱化原断言。
+
+HomePanel 及其原白名单内 PlayerShopData 配套会改变等待时机与失败分支，不能称零行为影响。HomePanel 原调用链为补单发放→礼包拍脸→暂存奖励 Flush→ShowData→CurRewardQCount/进度条/OnNoReward→启动 MaskClose。现补单方法内部逐单捕获错误后继续并清列表；方案拟改确认后继续、失败留待处理。该差异涉及订单状态和界面推进，须单独核证。
+
+原方案“成功且仍当前后继续原后续；失败留待处理”不够精确：若 await 异常、结果未知或提前 return 跳过整个后续，会连带阻止普通界面收尾与 MaskClose，可能卡住主页。不得按此模糊表述直接编码。
+
+## 修订必须满足的边界
+
+1. 保持原补单资格、奖励内容/数量、订单关联、活动事件及平台确认协议；PF 原路线不引入 KV 确认等待。
+2. 分清补单持久化成功、奖励成功展示、普通界面收尾三个职责。失败不能展示已保存/再次发奖，也不能把主页剩余逻辑整体截断。正常收尾须在当前界面生命周期内完成；旧界面回包不能操作新界面。
+3. TriggerPack 与暂存奖励本身可能继续改档，不能在 KV Unknown 下为了界面继续而盲目执行。逐项确认哪些后续只是界面收尾，哪些依赖已确认补单/可写存档；明确待处理状态与恢复时点，禁止永久冻结、静默丢队列或自动重放。当前文档尚不证明恢复策略已解决。
+4. 无补单时保留原快速路径。正常单笔/多笔顺序与原流程对照；覆盖无补单、成功、部分成功、拒写/Unknown、重复通知、销毁/退出、奖励队列和遮罩收尾。
+5. 三文件差异审查应先裁决上述正常与失败流程，再编码和验证。此补充不扩大文件白名单，不新增 Owner/Manager/事务协议，也不改变已审核心存储方案。
+
+当前结论：测试装配两文件可与生产流程严格隔离；HomePanel 方案存在真实流程影响风险，必须收紧后方可实施。不能将“只加 await”描述成对原流程没有影响。