docs(乐收赢): 订正 applyPayResult 里那段「为什么不放 payPatch」的注释

三处不实，一处自指，全部按实测改写。**不动任何生产行为**：本次提交的改动
经量具核过是纯注释（非注释改动行 = 0；同一量具在测试文件上读 35，正对照成立）。

一、h5 那一半是假话。
原写「/v3/qrpay 与 /v3/h5pay …那两个路径传的 patch 本来就没有 trade_no」。
实测 /v3/h5pay 的 PAY_SUCCESS 应答**带 trade_no**（200001070X4326092816045010002，
29 字段），payPatch 会照样落库。结论不变 —— h5 那条路径落的仍是 PAYING，
"SUCCESS".equals(newStatus) 根本不成立 ⇒ 同样不该响。错的只是「为什么」那半句。

二、把两件事混成了一件。
原写「isPaySuccess 为真的调用点恰好 4 个」。按谓词数不是 4（本条支付链上
`parser.isPaySuccess` 只有 3 处，且回调那处根本不经过该谓词 —— LsyNotifyService
自己算 newStatus 后直接调 applyPayResult）；按「谁在写 SUCCESS」数也不是 4，是 2。
改成按真实有承载力的口径：`applyPayResult` 在 main 里共 9 个调用点（本类 8 + 回调 1），
能写 SUCCESS 的恰好 2 个 —— settleFromQuery（字面量）与 handlePayNotify（变量 newStatus）。

三、行号是自指的。
原文写的 220/317/414 对不上；订正时新写的一组 234/340/448 同样对不上 ——
**写下这段注释的那个编辑本身**就把它引用的那几行往下推（实测：一次订正推 6 行，
两次共推 12 行）。行号在这里写完即失效，改为按**方法名**锚定，本段不再写任何行号。

判据的依据始终是**落的状态**（"SUCCESS".equals(newStatus)），既不是「有没有 trade_no」，
也不是「某个谓词为真」。这一点原文与订正后一致。

依据材料（本轮实测，均在 logs/ 下）：
- logs/_lsy-qrpay-resp.bin / _lsy-qrpay-resp-run1.bin —— 两发独立样本，各 12 字段，
  原文里**没有** trade_no 这个键（不是 null）
- logs/_lsy-h5pay-resp.bin —— 29 字段，有 trade_no
- grep 读数：applyPayResult( 共 9 个调用点；parser.isPaySuccess 本条链 3 处、
  main 里另有 6 处（取消/退款/详情查询三条腿，不写订单支付状态）

java/src/main/java/com/payment/platform/module/payment/leshouying/service/LsyOrderService.java

@@ -80,13 +80,33 @@ public class LsyOrderService {
             //
             // 【判据为什么挂在这里，而不是裁定字面写的 payPatch】裁定当时的措辞是
             //   「在 payPatch 里，当上游回了成功码而 trade_no 为空」。照字面放会**每笔主扫下单都误报**：
-            //   /v3/qrpay 与 /v3/h5pay 的 PAY_SUCCESS 描述的是「下单请求被受理」（完整机制见
-            //   createQrOrder 的注释），那两个路径传的 patch 本来就没有 trade_no，订单落 PAYING、
-            //   收款尚未发生 —— 没有 trade_no 是**正常**而非异常。响在这里就是告警疲劳，
+            //   /v3/qrpay 的 PAY_SUCCESS 描述的是「下单请求被受理」（完整机制见 createQrOrder 的注释），
+            //   该路径传的 patch 没有 trade_no（**实测** 2026-09-28：qrpay 的 PAY_SUCCESS 应答不含该字段），
+            //   订单落 PAYING、收款尚未发生 —— 没有 trade_no 是**正常**而非异常。响在这里就是告警疲劳，
             //   真告警会被淹掉，这项可见化等于白做。
-            //   【按调用点逐个量过，不是推断】全 main 里 isPaySuccess 为真的调用点**恰好 4 个**：
-            //   createQrOrder:220 / createH5Order:317 落 PAYING（都不该响），
-            //   settleFromQuery:414 与回调 LsyNotifyService 落 SUCCESS（都该响）。
+            //   ★【2026-09-28 订正】此处原写「/v3/qrpay 与 /v3/h5pay …那两个路径传的 patch 本来就没有
+            //     trade_no」—— **h5 那一半不实**：实测 /v3/h5pay 的 PAY_SUCCESS 应答**带 trade_no**
+            //     （200001070X4326092816045010002），payPatch 会照样把它落库。**结论不变**：
+            //     h5 那条路径落的仍是 PAYING，下面 `"SUCCESS".equals(newStatus)` 根本不成立 ⇒ 同样不该响。
+            //     错的只是「为什么」那半句。判据的依据始终是**落的状态**，不是「有没有 trade_no」。
+            //   【按调用点逐个量过，不是推断】`applyPayResult` 在 main 里共 **9 个**调用点
+            //     （本类 8 + 回调 1），其中**能写 SUCCESS 的恰好 2 个**：
+            //     `settleFromQuery`（传字面量 "SUCCESS"）与回调 `handlePayNotify`（传变量 newStatus）。
+            //     其余 7 个写 PAYING / FAIL，下面这个条件根本不成立 ⇒ 都不该响。
+            //   ★【2026-09-28 订正】此处原写「`isPaySuccess` 为真的调用点**恰好 4 个**：
+            //     createQrOrder:234 / createH5Order:340 落 PAYING，settleFromQuery:448 与回调
+            //     LsyNotifyService 落 SUCCESS（都该响）」。三处不实：
+            //     ① 把两件事混成一件：本条支付链上 `parser.isPaySuccess` 只有 **3 处**（全在本类；
+            //        回调那处**根本不经过该谓词** —— `LsyNotifyService` 自己算 newStatus 后直接调
+            //        `applyPayResult`）。所以按谓词数不是 4，按「谁在写 SUCCESS」数也不是 4（是 2）。
+            //        （main 里另有 6 处 `parser.isPaySuccess`，在取消 / 退款 / 详情查询三条腿上，
+            //          不写订单支付状态，不在本判据的作用域内。）
+            //     ② 原文那三个行号（220/317/414）实测对不上；订正时新写的一组（234/340/448）同样对不上。
+            //        **机制**：写这段注释这个动作本身就会把它引用的那几行往下推，每次订正再推一次
+            //        （实测：一次订正推 6 行，两次共推 12 行）。行号在此处是自指的，写完即失效
+            //        ⇒ 本段改按**方法名**锚定，不再写任何行号。
+            //     **结论不变**：判据的依据始终是**落的状态**（下面那句 "SUCCESS".equals(newStatus)），
+            //     既不是「有没有 trade_no」，也不是「某个谓词为真」。
             //   ⇒ 挂到「真的要写 SUCCESS」这一刻，**真阳性一个不少**，假阳性归零。
             //     这里还额外拿得到 order（payPatch 拿不到），日志因此能带上单号。
             //