What to build: 平台运营在后台把一个**已在汇付侧完成进件**的商户接到我方某个商家上，使它能在我们商户端直接使用并收款；绑定错了能解绑重来。
后台入口：在「财务管理 → 结算记录 → 商户进件」页签的筛选栏放一个纳管按钮，点开是对话框——选我方商家 + 填入汇付商户号 + 入驻申请单号（结算卡号不用填，从通道查回来）。提交后该商家立刻出现在进件列表里，进度收敛后即可收款。
同一个汇付商户号可以被多个商家分别纳管（连锁各门店共用一个收款主体），入口只提示已绑的商家、不拦截。
解绑入口在「商户进件详情」页，与既有的刷新进度 / 重试失败步骤 / 查询通道状态 / 发起微信实名并列，作为危险操作。
Blocked by: None — can start immediately
Status: ready-for-agent
纳管入口（后台）
- [ ] 「商户进件」页签出现纳管按钮，点开对话框可选我方商家、填汇付商户号与入驻申请单号；提交后列表可见该进件记录，并可直接进入详情。
- [ ] 纳管前用我们自己的签名身份只读查询一次；**查不到该商户时明确拒绝**并给出原因。
- [ ] 对话框展示通道返回的**商户注册名称**与**商户简称**（以及主体类型：企业/个人），由运营与所选商家核对并**显式勾选确认**后才能提交。
- [ ] 不用字符串比较判定名称是否「对得上」：我们这边只有一个商家名，通道那边是工商全称加简称，形态不对应，规则化匹配必然误判——误拒会把运营卡死且无路可绕，误放等于没设防。
- [ ] 通道侧的两个名称与所选商家名**连一个字符都不重叠**时给出醒目警示，但**不硬拒**（可能是简称、别名或服务点名）。
- [ ] 把通道侧的主体名写进件记录，使进件列表能同时看到我方商家名与通道主体名，便于事后核对与追责。
- [ ] 该汇付商户号已经被其他商家绑定时**只提示不拦截**，提示里列出已绑的商家。
- [ ] 该商家/门店**已经有一条进行中或已通过的进件**时拒绝并说明（避免同一门店出现两个收款主体）。
- [ ] 重复纳管同一个商家是幂等的，不会产生第二条进件记录。
- [ ] 纳管同时为该商家建立结算卡记录；卡号与绑卡序列号从通道的商户详细信息查询取回，沿用现有的字段级加密与卡号哈希，不新造一套。
- [ ] 进件记录的非空字段（主体类型、主体名、联系人、联系电话等）由通道查询反填，拿不到的从我们的商家记录取，不留空。
- [ ] 进件记录上标明来源为「纳管」，与自助进件区分。
- [ ] 纳管**全程只查询、不下发**：不调用任何补开、绑定、改口径类的下发接口。
- [ ] 纳管入口不创建商户端登录账号；若该商家还没有登录账号或未开启商户端登录，给出提示。
纳管之后的收敛
- [ ] 纳管触发一次进度刷新，分阶段进度与收款能力快照在**既有模型**内落库，不新造并行链路。
- [ ] 进度刷新在只有汇付侧入驻申请单号（没有我方发起的申请单号）时仍能推进，不会永远停在未确认。
- [ ] 收敛后该商家能通过下单闸门收款（与自助进件走完全相同的收款就绪口径）。
- [ ] 不新增任何进件定时任务或页面自动轮询。
- [ ] 商户端登录后能看到与下单闸门一致的「能否收款 + 原因 + 最近核实时间」，以及待办理项（含实名二维码）。
- [ ] 通道查询失败时保留上一次的进度，不显示为失败。
解绑
- [ ] 进件详情页出现解绑（危险操作，二次确认）。
- [ ] 该商户号上还有在途订单或待结算资金时拒绝解绑并说明原因。
- [ ] 解绑清理进件记录与结算卡记录，结算卡同时从「银行卡申请」页签消失；解绑后页面回到列表。
- [ ] 解绑只解除我方绑定，界面明确说明通道侧的改动不会被回退。
- [ ] 解绑不动商户端登录账号；解绑后可以重新纳管。
边界与兼容
- [ ] 迁移只新增一列（来源标记），编号取 V157，可重复执行。
- [ ] 纳管与解绑的接口放在既有的进件查改前缀之下，沿用现有的商户结算权限码，不新增权限码、不改共享的权限映射。
- [ ] 不新增前端路由。
- [ ] 自助进件的既有流程与存量商户行为不受影响。
测试与验收
- [ ] 接口级测试覆盖：纳管成功、通道查不到、主体名不符、已被其他商家绑定（提示但放行）、重复纳管幂等、该门店已有进行中/已通过进件的冲突、解绑、解绑的在途资金拦截；使用真实测试库与模拟汇付响应，**不创建真实汇付商户**。
- [ ] 支付链路全量测试通过（仓库既有基线失败除外）。
- [ ] 拿**一个**真实的外部进件商户端到端走通：后台纳管 → 进度收敛到收款就绪 → 商户端能登录并看到已就绪 → 真实收一笔。
