fix(merchant): 修正存量商户微信补开的请求组装与审核中判定
2026-09-15 对指定存量商户 6666000241335656 做真实补开时逐项撞出来的缺陷：
前两次请求被通道拒绝、第三次受理。修复后应用自己发出的请求与探针逐字相同。
- media_mer_common_flag 从顶层移进 online_media_info_list 元素。它是媒介元素的字段，
放顶层会被拒：`基础参数校验失败:【media_merCommon_flag-媒介主体与商户主体是否一致】不能为空,或格式非法`。
之前那次「补上顶层字段」的修复从未真正生效——当时没有可用权限去验证它。
- 线上三个场景一起开（4 线上公众号／5 线上小程序／12 线上反扫），原先只发场景 5，
另外两条支付路径在通道侧就没有配置。场景 12 在汇付费率规则表里没有独立行，与 4/5 共用同一线上规则。
- 企业微信开通使用 fee_rule_id（cid）代替 mcc：官方《微信费率规则ID》表里企业线上只有 756 一条，
细分行业含「就业信息平台／其他信息服务平台」；费率默认由 0.60 改为 0.70。
- 去掉 use_chains_flag=3。它要求上级本身有商户级微信配置，而我们的上级是渠道商
（查询返回 huifuId不存在），实测被拒：`失败:复用交易信息，上级商户号为空`。
不下发该字段时，子商户在渠道 00016904 下取得自己的微信子商户号。
- 运营媒介改为按 merchant-online-media-name 下发、默认留空：文档写明它只在开通快捷／网银／
余额支付Pro／分账／大额转账／代扣时才需要，且声明 media_mer_common_flag=N 会连带索要
授权或开发证明材料，而平台是一个小程序服务多个商户。
- 回执把 90000000（审核中）计入已受理，与两个进件网关的判定保持一致。真实补开返回的正是它，
照原判定会被记成 business_open_status=failed，两端页面会把已开好的商户显示成失败。
验证：真实补开受理（apply_no=2026091530554624），三个场景 wx_conf_status=S、入驻成功，
delay_flag 由 N 变 Y，人才端 AppID 绑定读回成功。定向测试 29 项全绿；全量 198 项仅
docs/agents/testing.md 所列的 3 项基线失败，无新增。
