fix(进件): 订正 createMerchant 的 javadoc 小标题与计数（末轮整支评审 F1 + 我复量出的第二处）

最终整支评审（`663156f..a9d1b83`，37 提交 / 39 文件 / +11109 −27）报回 1 条 Low：
`LsyOnboardingService.java:342` 的小标题「③ 组装：三处取值**不属于调用方**」被它自己
引入的第三条（`:349`「`rate_code`：DTO 有值以 DTO 为准」）推翻。我复量确认：`:1225` 的实现是
`isBlank(dto.getRateCode()) ? props.getRateCode() : dto.getRateCode()` ⇒ 调用方给了值就以
调用方为准，与「不属于调用方」相反。危险方向很具体：将来给这条腿加调用方的人按小标题会
得出「rate_code 是平台级、调用方设不了」，进而**删掉 DTO 那个覆盖口**。

★ 顺带复量出**评审漏掉且主动开脱**的第二处（同一个 javadoc 段）：「其余 54 个字段**原样透传**」。
评审给的开脱理由是「55 − 1 = 54，算得对」—— 它自己给的分组「4 信封 + 2 派生 + 1 rate_code + 54」
本身就是 **61 ≠ 60**，算错了。真值有两支互相独立的量法：

  ① 按键名分类：`merchantParams` 共 60 个 `p.put`，减去 `trace_no`（随机信封）、`notify_url` /
     `channel_id` / `bd_id`（配置）、`merchant_type` / `account_type`（类别派生）、`rate_code`
     （条件覆盖）⇒ 原样透传 **53**；
  ② 按表达式分类：60 个 put 里 4 个非 DTO 源 + 56 个 DTO 源，其中 `merchant_type` / `account_type`
     由 `dto.getCategory()` 派生、`rate_code` 带三目 ⇒ 直通 **53**（两法逐位相同）。

根因：DTO 是 **55** 个字段，`category` 只用于派生上面两个码值、自身**不上送**，`rate_code` 见上
⇒ 原样透传 = 55 − 1 − 1 = **53**。原句的 54 是「DTO 源键数」（含 rate_code），与它自己紧跟的
「原样透传」这个谓语对不上 —— 定语又一次与正文相反，本批第三次同形。

★ 注意**不要**据此去改测试：`LsyOnboardingServiceTest.expectedMerchantParams()` 的分组横幅写
「非 DTO 的 5 个」「DTO 的 **54** 个」，那是它**自己**的口径（横幅里逐字注明「rate_code 这里取
DTO 的值 ⇒ 覆盖配置」，即 54 里含 rate_code），两支量法都实测过：5 + 54 = 59，加 `trace_no` = 60，
且测试键集 == 实现键集 − {trace_no}（双向差集皆空）⇒ 那边是**对**的，两者不矛盾。

改法（两条 javadoc 行，措辞去掉了「不属于调用方」这个假定语，并把 53 写成可自检的算式）：
  :342  【③ 组装：三处取值不属于调用方】 → 【③ 组装：三处取值各有自己的规则】
  :352  其余 54 个字段**原样透传**： → 其余 53 个字段**原样透传**（= DTO 的 55 个字段 −
        只用于派生的 category − 上面单列的 rate_code）：

静息状态**逐字节无行为变化**（比「测试还是绿的」更强的一支证据）：改后行数不变
（CR=1485 / LF=1485，行尾仍 CRLF），于是 javadoc 文本不进 .class 这条成立 ⇒ 编出来的
`LsyOnboardingService.class` sha256 **= 改前的 909cf5898485a6cc…f0e337c，完全相同**；
且 .class mtime 14:22:55 **晚于**源码 mtime 14:22:20 ⇒ 这份 class 确实是拿改后的源码编的，
不是陈旧产物。diff 读数 2 增 2 删，非注释行 0 条。

回归：Tests run: 645, Failures: 0, Errors: 0, Skipped: 0（BUILD SUCCESS；需库隧道在位）。

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

@@ -339,7 +339,7 @@ public class LsyOnboardingService {
      * 类别为 {@code null} 时矩阵报的是两个派生字段（{@code merchant_type} / {@code account_type}），
      * 同样是 400，**不是** 500。
      *
-     * <p><b>【③ 组装：三处取值不属于调用方】</b>
+     * <p><b>【③ 组装：三处取值各有自己的规则】</b>
      * <ul>
      *   <li>{@code merchant_type} / {@code account_type} <b>从类别派生</b>（{@code dto.getCategory()}，
      *       DTO 上不存这两个码值）；★ 走到这一步类别**必然非 null** —— 类别为空在 ② 就被拒了
@@ -349,7 +349,7 @@ public class LsyOnboardingService {
      *   <li>{@code rate_code}：DTO 有值以 DTO 为准，没有则取配置（计划 §0.8 的裁定 ——
      *       该字段归属未定，先按平台级实现、把逐商户覆盖的口子留在 DTO 上）。</li>
      * </ul>
-     * 其余 54 个字段**原样透传**：{@code null} 照常放进 map（{@code LeshouyingClient} 按既有规则
+     * 其余 53 个字段**原样透传**（= DTO 的 55 个字段 − 只用于派生的 {@code category} − 上面单列的 {@code rate_code}）：{@code null} 照常放进 map（{@code LeshouyingClient} 按既有规则
      * 剔 null，服务层不重复一条口径 —— 两份「什么算没填」分叉的症状是「有的字段被剔了、有的没有」），
      * 空串则原样上送（与本仓签名规则「null 不参与、**空串参与**」同源）。
      * ⇒ <b>未填的非必填字段应当传 {@code null}（缺键），不要传空串</b>：空串是一个参与签名的真实值。