fix(merchant): 进件回调不再拿着数据库事务去等汇付 HTTP
微信商户配置回调与商户业务开通回调都是先 select ... for update 锁住进件记录，然后在事务里
同步调用汇付接口（v2.merchant.busi.config / v2.merchant.busi.open）。这等于拿着这条记录的
行锁和一条数据库连接去等一个不受控的网络响应：一旦汇付慢，连接被占住，而
merchant_onboarding_application 上的查询会连带排队。
2026-09-15 后台全站不可用正是这个形态：一个空闲未提交事务持着该表的元数据锁，
ALTER 无限等锁，该表所有查询排队，10 条连接的池子很快借光，健康检查都超时。
改动：
- 新增 runAfterCommit(Runnable)：有活动事务就注册 afterCommit，否则立即执行。
- 两个回调里对后续配置的调用改为提交后再做（continueProvisioningAfterCommit /
completeProvisioningAfterCommit）；回调自身只负责把通道结果落库。
后续配置有自己的重试入口（业务开通回调、主动轮询），不会被回调事务的成败牵连。
- refreshCapabilityAfterCommit 复用同一个 helper，去掉重复实现。
- application.yml 打开 Hikari leak-detection-threshold=10s：池只有 10 条连接，
超过 10 秒未归还的连接会连调用栈一起打进日志，下次能直接定位是谁在长事务里等外部调用。
回归：回调幂等、进件重试、支付结算等共 44 项通过。
