docs(汇安融): 10.5 的回调兜底提醒补上退款这条

10.5 原来只写了「给长期停在 0 的订单做主动查询兜底」——退款上线后，
订单还会停在 "4"（退款中），而那正是**等钱**的状态，比 "0" 更要紧：
停在那儿意味着用户的钱退没退还不知道。

补一条说明退款终态走同一条回调（content.status + refund_time），
以及 "4" 同样需要主动查询兜底。

顺带记下这次量到的代码事实（写文档时的依据）：
- notifyEnterprise 全仓只有 1 个调用点（HarNotifyService.handle），
  即**只有上游推了通知才会回调下游**；主动查询那条路
  （syncFromUpstream → applyQueryDetail）不回调。
- 而 HarOrderService:405 的注释自己写着「上游通知重试窗口只有约 25 秒，
  超过即永久丢失，因此主动查询是状态收敛的主路径，不是兜底」。
  两者合起来 = 退款收敛到 "2" 这件事，下游多半收不到回调。

只改 md，不动代码。「轮询收敛后也补一条回调」是另一件事，需要设计
（去重、与通知路重复投递、notify_status 语义），未裁定。

frontend/src/views/module_payment/apikey/docs/har-openapi.md

@@ -274,6 +274,8 @@ Content-Type: application/x-www-form-urlencoded
 
 > ⚠️ **平台只在收到上游通知时才会向你推送回调。** 若上游那条通知丢了，平台会靠自己的任务把本地状态收敛正确，但**不会**补推一条给你 —— 此时 10.3 能查到正确结果，你的回调却永远不会响。**请务必给长期停在 `"0"` 的订单做主动查询兜底。**
 
+> ⚠️ **退款的最终结果（`"4"` → `"2"` / `"1"`）走的是同一条回调**，`content.status` 里就是新状态，`refund_time` 也在里面。所以上面的兜底对退款**同样适用，而且更要紧**：退款停在 `"4"` 时你等的是钱有没有回来，回调不响就只能自己查。**给长期停在 `"4"` 的订单也做主动查询。**
+
 > ⚠️ **回调不带签名。** 与 7.2 的情况相同 —— 不能仅凭收到回调就认定收款成功。请以 **10.3 订单查询** 的结果为准，把回调当作「该查了」的触发信号。
 
 ---