fix(进件): 订正 createMerchant javadoc 里被复评量出的 3 处定语/计数错 + 1 处我自己的新括注

散查复评在我上一轮改的同一段 javadoc 里，报了 3 条落在**未改动行**上的同形缺陷
（结论对、定语或因果句错）。三条我都用自己的量具独立复现后才改，读数如下：

:305  信封枚举是 inst_no / trace_no / sign ⇒「后两个里的 inst_no 与 sign」自相矛盾
      （inst_no 是第一个；trace_no 才在后两个里，却又说它由本方法生成）。
      实测 LeshouyingClient.signedPayload:382-383 补的正是 inst_no + sign ⇒ 定语改「其中」。
:307  构成式 3 + 4 + 2 + 54 = 63，而真实上游入参 = 60 个 map 键 + inst_no + sign = 62：
      rate_code 同时被算进「配置四项」和「DTO 的 54 个业务字段」，数了两遍。
      改「配置三项 + rate_code（规则见 ③）」、DTO 桶 54→53 ⇒ 3+3+1+2+53 = 62。
      这同时消掉了与上一轮 :352「上面单列的 rate_code」的相互矛盾。
:314  凭据闸实测是五项（missingOnboardingCredentials:230/233/236/239/242 共五条 isBlank），
      原文「四项」漏了 channel_type；而 channel_type 不在那 60 个键里（生产代码只有
      mccList:749 读它）⇒「凭据缺失时连报文都补不全」在「只有 channelType 缺」下不成立。
      改为「五项，其中四项本身就是报文的一部分；第五项只喂 MCC 那条腿」。
:352  上一轮我写的「只用于派生的 category」：getCategory() 还被
      LsyMerchantRequiredFields:313 用来选必填集 ⇒「只」在排他读法下偏。改「自身不上送的」。

行数不变（CR=LF=1485）⇒ LineNumberTable 不变。且复评已把「javadoc 文本不进 .class」
从推断升级为直接实测（class 字节里 8 条 javadoc 探针 0 命中、3 条代码字面量正控 1/1/2 命中）。
本轮前后 LsyOnboardingService.class 逐字节相同（sha256 909cf589…e337c，改前读数由我自己采集），
class mtime 比源码晚 41.3s ⇒ 是拿改后源码编的，不是陈旧产物。全量 mvn clean test = 645 绿。

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

@@ -302,18 +302,18 @@ public class LsyOnboardingService {
     /**
      * 创建商户（上游 page 196236555，路径 {@code /api/merchant/create}）—— 三-B 的进件入口。
      *
-     * <p>上游入参 = 信封（{@code inst_no} / {@code trace_no} / {@code sign}；后两个里的
+     * <p>上游入参 = 信封（{@code inst_no} / {@code trace_no} / {@code sign}；其中
      * {@code inst_no} 与 {@code sign} 由 {@link LeshouyingClient} 在出站链路上补，
-     * {@code trace_no} 由本方法**每次新生成**）+ 配置四项（{@code notify_url} / {@code channel_id} /
-     * {@code bd_id} / {@code rate_code}）+ 类别派生两项（{@code merchant_type} / {@code account_type}）
-     * + {@link LsyMerchantCreateDTO} 的 54 个业务字段。
+     * {@code trace_no} 由本方法**每次新生成**）+ 配置三项（{@code notify_url} / {@code channel_id} /
+     * {@code bd_id}）+ {@code rate_code}（规则见 ③）+ 类别派生两项（{@code merchant_type} /
+     * {@code account_type}）+ {@link LsyMerchantCreateDTO} 的 53 个业务字段。
      * 出参：{@code result_code} / {@code result_msg} / 商户号 / {@code sign}
      * （信封非 SUCCESS 一律抛 {@code LeshouyingApiException} ⇒ 走得下去就说明上游**认了**这次进件）。
      *
      * <p><b>【四步，顺序不许换】</b>① 凭据闸 → ② 必填矩阵 → ③ 组装 → ④ 上送 + 取号。
-     * ① 排在 ② 前面是**硬的**，不是偏好：凭据缺失时**连报文都补不全**
-     * （{@code channel_id} / {@code bd_id} / {@code notify_url} / {@code rate_code} 四项里缺的任何一项
-     * 都是报文的一部分）。反过来先报必填的话，操作者会先把一整屏字段填完，再被告知「服务端配置没配」
+     * ① 排在 ② 前面是**硬的**，不是偏好：凭据闸共**五项**，其中四项（{@code channel_id} /
+     * {@code bd_id} / {@code notify_url} / {@code rate_code}）**本身就是报文的一部分**，缺一项报文就补不全
+     * （第五项 {@code channel_type} 只喂 MCC 那条腿，不在这里的报文里）。反过来先报必填的话，操作者会先把一整屏字段填完，再被告知「服务端配置没配」
      * —— 而**那个配置他改不了**，能改的人不在这个页面上。
      *
      * <p><b>【① 凭据闸：明细只进日志，对外只给中文固定文案 + 缺失项数】</b>
@@ -349,7 +349,7 @@ public class LsyOnboardingService {
      *   <li>{@code rate_code}：DTO 有值以 DTO 为准，没有则取配置（计划 §0.8 的裁定 ——
      *       该字段归属未定，先按平台级实现、把逐商户覆盖的口子留在 DTO 上）。</li>
      * </ul>
-     * 其余 53 个字段**原样透传**（= DTO 的 55 个字段 − 只用于派生的 {@code category} − 上面单列的 {@code rate_code}）：{@code null} 照常放进 map（{@code LeshouyingClient} 按既有规则
+     * 其余 53 个字段**原样透传**（= DTO 的 55 个字段 − 自身不上送的 {@code category} − 上面单列的 {@code rate_code}）：{@code null} 照常放进 map（{@code LeshouyingClient} 按既有规则
      * 剔 null，服务层不重复一条口径 —— 两份「什么算没填」分叉的症状是「有的字段被剔了、有的没有」），
      * 空串则原样上送（与本仓签名规则「null 不参与、**空串参与**」同源）。
      * ⇒ <b>未填的非必填字段应当传 {@code null}（缺键），不要传空串</b>：空串是一个参与签名的真实值。