docs(乐收赢): 人工标记失败 SQL 的前提段改用 11:40 实测读数（腿在跑、上游不回终局）

lsy-refund-stuck-diag.sql 已由用户执行（11:40:43），读数：两行仍 REFUNDING，游标新鲜
（updated_time 11:39:15 + 60s = next_query_time 11:40:15 —— pushNextReconcileTime 的指纹）
⇒ 对账腿在跑且在问，行不收敛不是「腿没跑」。

原文「对账腿一个多小时没收敛」是未测量的表述（事故 11:15、诊断 11:40，实为 25 分钟），
按实测改掉，并把残余可能收敛成两条：①每轮答复都不终局（上游回在途/查无）
②查询调用每轮失败（日志里有 WARN/ERROR）。两种都不会自愈。

java/src/main/resources/db/lsy-refund-manual-fail.sql

@@ -10,7 +10,10 @@
 --
 -- ── ★★ 执行前提（缺一不可）──────────────────────────────────────────
 -- 1) **必须先去上游（乐收赢/汇安融商户后台，或直接问上游）确认这两笔退款没有成功出金。**
---    本脚本的全部依据只有：同步应答说 PAY_FAIL（余额不足）+ 对账腿一个多小时没收敛。
+--    本脚本的全部依据只有：同步应答说 PAY_FAIL（余额不足）+ 对账腿不收敛
+--    （2026-10-06 11:40 实测：两行仍是 REFUNDING，游标新鲜 —— updated_time + 60s =
+--    next_query_time ⇒ 腿在跑；问到 PAY_FAIL/PAY_SUCCESS 都会当场落库 ⇒ 还停着只能是
+--    「每轮答复都不终局（上游回在途/查无）」或「查询调用每轮失败（日志里有 WARN/ERROR）」）。
 --    而 R11/R-1 这套「不落终态」的设计前提恰恰是「上游可能误报」——如果钱其实退出去了，
 --    写 FAIL 会放闸 ⇒ 同一张单可以再退一次 ⇒ **双重出金**。这是本脚本唯一的风险面，
 --    也是「为什么必须先人工核对」的全部理由。核对不确定 ⇒ 不跑本脚本。