Plan: 余额支付退款重复退款优化

背景

余额支付订单退款当前允许同一订单产生多条钱包进账流水，这是合理的：客户投诉、人工补退、重算补退等场景都可能需要追加退款。

本次优化不采用“一单只能插一次”的唯一约束，而是改为累计金额控制：

balancePaymentOrderRefund 和 balancePaymentOrderRefundV2 当前会按订单支付记录与消费金额重新计算本次退款金额。

如果同一订单已经存在部分退款流水，再次执行时没有按“目标退款金额 - 已退金额”计算差额，存在重复退款风险。

MemberBasicInfoServiceImpl.updateMemberBalance 使用 version 更新钱包余额，但当更新返回 0 时只打印日志，后续仍可能插入 member_wallet_log。

这会造成余额与流水不一致，也会影响后续已退款金额判断。

OrderBasicInfoServiceImpl.balancePaymentOrderRefundV2 没有已退金额校验，也没有累计退款上限。

重复调用时可能持续向会员钱包退款。

不限制同一订单只能插入一条退款流水。
同一订单累计余额退款总额不能超过余额支付总额。
自动结算退款以 order_basic_info.refund_amount 作为当前目标退款金额；如果需要客户投诉补退，应先把目标退款金额调整到新的业务目标，且不能超过支付总额。
本金与赠送金分别受各自支付金额上限约束。
钱包余额更新与钱包流水必须保持事务一致。

优先级：P0
状态：done
目标：补 balancePaymentOrderRefundV2 累计退款上限与差额退款。
设计：
- 查询订单已退本金、已退赠送金。
- 订单目标退款金额取 min(order.refundAmount, balancePayTotal)。
- 本次退款金额取 目标退款金额 - 已退总额 范围内的金额。
- 本金累计退款不能超过本金支付金额，赠送金累计退款不能超过赠送金支付金额。
验收：
- 同一订单重复调用 V2，不会超过当前目标退款金额。
- 如果目标退款金额被业务调整变大，可以继续补退，但累计不超过余额支付总额。

优先级：P1
状态：done
目标：统一新旧余额退款逻辑。
设计：
- 在 OrderBasicInfoService 提供统一的余额退款额度裁剪方法。
- DelayMerchantProgramLogic.balancePaymentOrderRefund、NotDelayMerchantProgramLogic.balancePaymentOrderRefund、OrderBasicInfoServiceImpl.balancePaymentOrderRefundV2 都复用同一套累计上限判断。
验收：
- 三条余额支付退款路径的已退金额口径一致。

优先级：P2
状态：done
目标：修复钱包更新事务一致性。
设计：
- updateMemberBalance 增加事务。
- memberBasicInfoMapper.updateMemberBalance(...) 返回 0 时抛异常。
- 钱包余额更新失败时不插入 member_wallet_log。
验收：
- 乐观锁失败时不会产生钱包流水。

优先级：P3
状态：done
目标：补充验证。
设计：
- 编译受影响模块。
- 对重复调用、目标退款金额调整、钱包乐观锁失败做回归验证。
验收：
- 编译通过，关键路径验证结果记录到本文档。
当前进展：
- 使用 JDK 8 执行 mvn -pl jsowell-pile -am compile -DskipTests 通过。
- 当前默认 JDK 21 执行 Maven 会在 jsowell-common 编译阶段触发老 Lombok/javac 兼容性错误，未进入本次改动编译。