refactor(db): 财务渠道迁移合并为单条 113

生产当前在 112，原 113–118 六条迁移合并为 113_finance_channel_cutover：
- 渠道/状态三列 + 从 fulfillment_mode 回填
- 删除旧列及旧索引
- 销售事实列改名 channel
- 财务管道增量索引（原 117/118）
- 移除不再使用的 refund_adjustment 约束（历史退款不入财务）

42 万行副本实测 49 秒完成；生产只需执行一条迁移，不再需要中间回填脚本。

docs/README.md

@@ -97,7 +97,7 @@
 ## 三、统一实施顺序
 
 ```text
-0. 统一履约事实（渠道 + 成本模型正交）   已完成（迁移 113–116）
+0. 统一履约事实（渠道 + 成本模型正交）   已完成（迁移 113）
 1. 商品主数据 + 渠道 SKU 映射                        已完成 P0（仅自动发货/接单平台）
 2. 成本中心 + 销售事实                              已完成 P0
 2.5 人工成本链路收敛（确认履约 → 扣积分/备用金 → 写快照）   已完成 P0（迁移 104）

docs/dev合并main评估-2026-10-27.md

@@ -1,7 +1,7 @@
 # dev 合并 main 评估（2026-10-27）
 
 
-> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–116 删除；
+> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113 删除；
 > 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
 > 本文保留用于追溯当时的决策，不再作为实现依据。
 > 评估对象：`main`（2fb7aae1）与 `dev`（0de0fd7b + 当前未提交的财务 P0/P1 改动）。

docs/成本中心API契约.md

@@ -1,7 +1,7 @@
 # 成本中心 API 契约
 
 > 状态：**现行**。后端服务与前端页面都必须严格按此实现，不得各自发挥。
-> 最后校准：2026-10-31（履约渠道模型，迁移 113–116）
+> 最后校准：2026-10-31（履约渠道模型，迁移 113）
 > 代码基线：`main`
 > 详细业务口径见 [财务与履约口径总纲-2026-10-23.md](财务与履约口径总纲-2026-10-23.md)；数据模型见 [成本中心与履约模型.md](成本中心与履约模型.md)。
 

docs/成本中心与履约模型.md

@@ -1,7 +1,7 @@
 # 成本中心与履约模型
 
 > 状态：**现行**。2026-10-31 起履约事实改为「渠道 + 状态」两列，旧 `fulfillment_channel` 已删除。
-> 最后校准：2026-10-31（迁移 113–116）
+> 最后校准：2026-10-31（迁移 113）
 > 代码基线：`main`
 > 数据基线：2026-10-29 生产 dump；历史数字仅作迁移参照。
 > 上线初始化/验收见 [财务上线初始化与验收-2026-10-26.md](财务上线初始化与验收-2026-10-26.md)。

docs/财务与履约口径总纲-2026-10-23.md

@@ -1,7 +1,7 @@
 # 财务与履约口径总纲（2026-10-23 重写版）
 
 
-> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–116 删除；
+> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113 删除；
 > 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
 > 本文保留用于追溯当时的决策，不再作为实现依据。
 > 状态：**已归档**。现行口径见《成本中心与履约模型》（2026-10-31 校准）与《成本中心API契约》。

docs/财务流程总览-2026-11-01.md

@@ -2,7 +2,7 @@
 
 > 状态：**现行**。断代日 `2026-10-31`：历史订单全部归档，财务只统计断代之后的数据。
 > 历史订单的退款不进入本系统财务口径，由业务侧自行处理。
-> 代码基线：`main`（迁移 112–118）。
+> 代码基线：`main`（迁移 112–113）。
 
 ## 一、范围与原则
 
@@ -131,6 +131,21 @@
 3. 写入断代记录，重复执行会被拦截；
 4. 之后只处理新订单，无需任何历史回填。
 
+### 11.1 升级步骤（生产 112 → 113）
+
+原 113–118 已合并为一条 `113_finance_channel_cutover`（含渠道回填、删旧列、事实列改名、管道索引）：
+
+```bash
+# 1. 备份
+# 2. 迁移（42 万行实测约 50 秒，期间 order_items 会短暂持锁）
+npm run db:migrate
+# 3. 断代：归档历史 + 清空派生数据
+npm run finance:cutover-v2 -- --execute --confirm=2026-10-31
+# 4. 部署代码，启动后台
+```
+
+迁移内部已包含 `fulfillment_mode → fulfillment_channel/status` 回填，不再需要单独的回填脚本。
+
 ## 十二、运维
 
 - 后台「履约渠道 → 管道状态」查看水位、最近成功、错误；

docs/财务系统深度分析-2026-10-27.md

@@ -1,7 +1,7 @@
 # order_site 财务系统深度分析（2026-10-27）
 
 
-> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113–116 删除；
+> **历史文档（2026-10-31 前口径）**：文中 `fulfillment_mode` / `legacy_platform` 已随迁移 113 删除；
 > 现行口径为 `order_items.fulfillment_channel + fulfillment_status`，销售事实维度为 `sales_daily_facts.channel`。
 > 本文保留用于追溯当时的决策，不再作为实现依据。
 > 分析对象：订单履约、成本中心、客服备用金/积分、销售事实、影子总账、期间关账与平台对账。

docs/财务系统集成方案.md

@@ -20,7 +20,7 @@
 | 商品主数据 / 渠道 SKU 映射 / 成本中心 | **已实施 P0（`dev` 分支）**，迁移 `103/104`；标准商品 745 个，只覆盖自动发货 38 + 接单平台 707 |
 | `sales_daily_facts` / 订单级毛利 | **已实施 P0（`dev` 分支）**，迁移 `105`；94 天收入 ¥2,650.87 万、成本 ¥950.27 万 |
 | 人工成本录入（确认履约 → 扣积分/备用金 → 写快照） | **已实施 P0（`dev` 分支）**，迁移 `104/107`；2026-10-24 人工履约页下线、入口收敛到订单页；**无登记单、无审批、无报销** |
-| 履约渠道统一 `fulfillment_channel + fulfillment_status` | **已实施（2026-10-31，迁移 113–116）**；旧 `fulfillment_mode` 已删除，订单/成本/事实统一读渠道 |
+| 履约渠道统一 `fulfillment_channel + fulfillment_status` | **已实施（2026-10-31，迁移 113）**；旧 `fulfillment_mode` 已删除，订单/成本/事实统一读渠道 |
 | `finance_accounts` / `finance_journal_entries` / `finance_journal_lines` | **已实施 P0（迁移 108）** |
 | `finance_periods` / `finance_reconciliations` / `finance_reconciliation_items` | **已实施 P0（迁移 108）** |
 | `finance_business_events` / `finance_settlements` | 未实施（当前用条目唯一键幂等） |