chore(汇安融): 订正那份交付 SQL 里的退避读数 —— 封顶 5 分钟，不是 15 分钟

上一版注释里写了「退避封顶 900 秒 ⇒ 每 15 分钟报一次」，是我按 nextDelaySeconds 的
javadoc 那句「30s → 1m → 2m → 5m → 15m 封顶」顺手写的，没去量**这一条路**走的是哪一支。

实测（HarOrderService#nextDelaySeconds，第 577-581 行）：
查询失败走 finalStateKnown=false 那一支 —— `count <= 3 ? 60 : 300`，
即 60 秒 → **封顶 300 秒（5 分钟）**。15 分钟那个封顶属于「拿到了明确的非终态」的正常退避。
⇒ 现象是**每 5 分钟报一次、永远不停**，不是越来越稀疏到消失。

只改注释里的数字，判定条件与 SQL 一字未动。（a5fbd76 的提交信息里同样的数字也是错的，
那个改不动了 —— 记在这里，别照那句读。）

java/src/main/resources/db/har-close-rejected-orders.sql

@@ -12,8 +12,10 @@
 -- 旧版 create 是「先落库、再发上游」，失败分支只改了 description，而 trade_status 停在
 -- 「0 等待支付」、next_query_time 已经排到 30 秒后。轮询按 trade_status IN ('0','4')
 -- 捞单（HarOrderMapper#findPendingForPoll），于是这些行每轮都被捞起来去上游问一笔
--- **在上游从来没被建出来**的订单 —— 日志里一直刷「查询返回非成功码 / 找不到订单」，
--- 退避封顶 900 秒也只是把「一直报」拉长成「每 15 分钟报一次」。
+-- **在上游从来没被建出来**的订单 —— 日志里一直刷「查询返回非成功码 / 找不到订单」。
+-- 退避不是没有：查询失败走 nextDelaySeconds(count, false)，60 秒 → 封顶 300 秒
+-- （5 分钟，不是 15 分钟 —— 15 分钟那个封顶属于「拿到了明确的非终态」那条正常退避），
+-- 所以现象是**每 5 分钟报一次、永远不停**，而不是越来越稀疏到消失。
 --
 -- 收尾动作与代码里那两格完全一致：trade_status 置 '8'（不在 PENDING 里，捞单条件立刻失效）
 -- + next_query_time 写回 NULL。