## Why

当前所有线上支付依赖一份综合支付配置，无法按支付方式在多个实际收款商户之间受控轮询；已存在且可达的回调、查单和原路退款路径也缺少冻结商户事实，无法在商户停用后继续安全加载对应凭证。

本 Change 落实 AUG26-002：将收款商户、支付路由和 C 端微信授权分离，并以商户池快照取代新业务对旧综合支付配置的依赖。

## What Changes

- 新增独立商户管理：微信商户与支付宝商户分别建档；商户保存支付能力和敏感凭证，但历史支付单仅保存非敏感身份快照。
- 新增每种支付方式至多一个启用商户池，支持按成功收款金额、成功笔数或时间周期轮询；新支付仅从命中池选择实际商户。
- 新增全局唯一启用的微信授权配置，专供 C 端公众号 H5/JSSDK、小程序登录、OpenID 和支付 AppID；它不是微信收款商户。
- 新建 C 端套餐购买、资产钱包充值、代理在线预存款充值按商户池路由；后台线下/钱包支付不经过商户池。代理全局允许范围、其与商户池方式的交集及对外方式查询仍由对应代理自充 Change 负责；本 Change 只在方式已获准后选择实际商户。无可用商户时失败，不得回退旧配置或自动换商户重试。
- 迁移完成后部署支持按 merchant ID 或旧 `payment_config_id` 双读的 API/Worker；三类后续新支付立即只走商户池并冻结路由，无可用池、成员或停用池时明确失败且不回退旧综合支付配置。merchant ID 为空的仅为历史订单，继续处理其自身回调、查单和已有可达的原路退款，直到独立 Change 按数据留存期删除旧读取路径。
- 零条当前生效综合支付配置时仅创建新 Schema 和管理入口，不插入空商户、空商户池或空微信授权配置；新线上支付明确失败，微信授权功能明确返回未配置。富友 `CommonQuery` 保持现有请求、签名、验签、状态和恢复兼容基线，只实现本地双读凭证与商户加载，不改协议或退款；未第三方实测可记录但不构成本 Change 实施或归档阻塞。验证在本地工作区以明确 `DB_*` 指向维护者指定的 `junhong_cmp_test` PostgreSQL、Redis DB6 执行；完成后才提交推送 Iteration/8-11，由 Gitea 构建/部署 `cmp-test` 测试镜像并检查迁移版本，日志位于 `/opt/junhong_cmp/logs`，不重置整库。

## Capabilities

### New Capabilities

- `merchant-payment-routing`: 商户、商户池、微信授权配置、轮询、历史商户快照和迁移切换行为。

### Modified Capabilities

- 无。该能力向既有支付创建、回调、查单和已有原路退款调用链提供已选商户事实，不改变既有资金幂等不变量，也不新增渠道退款能力。

## Impact

影响支付配置模型和后台接口、`tb_payment`/订单/充值支付关联、微信/支付宝/富友支付加载和回调、支付与退款审计、敏感信息访问及新增成对迁移。