weicw1996
13cb08621f
feat(hjc): 买家可取消待支付订单；标书详情「购买人数」改实时统计
取消订单（POST /api/hjc/order/cancel，幂等）：
- 先向微信查单。SUCCESS 则**拒绝取消**并就地 markPaid 自愈（ADR 0009 的「以微信侧为准」）；
这是唯一能挡住「其实已付款、只是前端没送达」的时机
- 否则条件更新 order_status=2：
UPDATE ... WHERE order_no=? AND pay_status=0 AND order_status=0
靠**影响行数**保证幂等与安全，故新增 XML <update>——updateById 那条路拿不到行数
- 再尽力 closeOrder 关掉微信侧那张支付单，避免「已取消却仍能付款」；失败只记日志、不回滚
- 查单异常时仍放行取消，但响应带 verified=false，如实告知「未与微信核对」，不替微信下结论
- 响应恒 code=0 + 结构化 data{cancelled,paid,verified,payStatus,orderStatus}：
「其实已经付了」不是错误，不该让前端靠 message 字符串判定
- 结果以**重新读到的状态**为准，不以条件更新返回值为准（并发重复取消 / 期间被支付）
- **不推送一站式**。出向状态只有 PAID/REFUNDED，且 buildCreatePurchaseDetails 对非退款单
恒发 PAID——在取消路径误调会造出一条假的「已支付」采购记录。未支付订单从未被推送过
标书详情新增 buyerCount（非表字段，实时统计的已付款订单数）：
原「购买人数」取自 saleCount——下单即加、从不回退，dev 实测项目 4 的 16 里 11 张根本没付款。
saleCount 字段与下单累加未动（已无展示用途），**零 DDL**。
/order/pay 失败响应带 data.wechatCode：从 PaymentException 的 cause 链取
ServiceException.getErrorCode()（SDK 原样挂在 cause 上，中途各级 catch 全是 throw e），
供前端识别跨端 OUT_TRADE_NO_USED。**公共支付层与 core 一行未改。**
测试：HjcOrderCancelUtilTest(9) + HjcOrderControllerCancelTest(12，含推送禁区回归守卫)