docs(进件): Task 3 修复轮 2 - 三处 javadoc 措辞订正（零行为改动）

修复轮 2 只改注释文字，不动夹具、不动 labelsIn、不动任何断言与方法体。

1. MERCHANT_MICRO_MISSING_LABELS 的 javadoc：删掉「一条是另一条的前缀时 contains 唯一抓不到」
   这句假话 —— 前缀只是「改了标签文案、却让每个期望标签仍然原样留在文案里」这一类里的一个成因，
   把标签改长（商户客服电话 → 商户客服电话（座机或手机））、加尾巴同样过得了旧的逐条 contains。
   同时把原句的「恒真」改成按范围精确的表述（这一组 26 条 contains 断言全过），
   并把判据的射程写成该类的定义 + 换成切分判据后这一类都会红。
2. 同段两个前提后补一句代价：该判据对文案外形的改变会假红、且失败信息指错方向
   （加尾巴 / 「）：」后加空格 / 前缀改写引入更早的冒号），并写明这是取舍不是疏忽
   （要对尾巴钝感就得放弃数量相等，而「多一个」「26 个都在、另有一个重复」只有数量能抓）。
   判据本身不改。
3. createMerchant_readsMerchantNoFromEitherKey 的 javadoc：把「两个键本该是同义别名、正常只会
   有一个有值」从 spec §6.2(c) 的归因里拆出来，明确标成我们的读法（spec 只说返回参数表与返回示例
   各写了一个键，结论是「创建成功后到底从哪个 key 取号，只有真跑一次才知道」）。
   「返回参数表写一个、返回示例写另一个」这半句正确的映射逐字保留。

验证：git diff 27 行全部落在 javadoc 行（无代码行 / 断言行 / 夹具项）；
LsyOnboardingServiceTest 改前 57 绿、改后 57 绿；
.class sha256 5a16a00c… → c64b2a31…（-g 打开，LineNumberTable 进 class），
javap -c -p -l 比改前改后差异只在行号（+11 / +13），常量池逐行相同。

java/src/test/java/com/payment/platform/module/payment/leshouying/service/LsyOnboardingServiceTest.java

@@ -1604,14 +1604,25 @@ class LsyOnboardingServiceTest {
      * <p>★ 断言是把文案里「：」之后的清单**按「、」切回来**再比（数量与集合都相等 ⇒ 多重集相等），
      * 所以这个数组的**排列不参与断言** —— 排成矩阵声明顺序只为读起来能跟那张表逐行对照。
      *
-     * <p>★ 修复轮 1（F1）之前这里用的是逐条 {@code contains}，那是**恒真**的：
-     * 数组里「商户签约负责人」是「商户签约负责人电话 / 邮箱」的前缀，改掉前者那条标签文案，
-     * 后两条自己就把前缀带出来了。切分之后「少一个 / 多一个 / 串一个 / 一条是另一条的前缀」
-     * 才会红 —— 这正是一条是另一条前缀时 {@code contains} 唯一抓不到的情形。
+     * <p>★ 修复轮 1（F1）之前这里用的是逐条 {@code contains}：它只问「期望标签在不在文案里」，
+     * 不问「文案里那一段是不是正好就是期望标签」⇒ 只要每个期望标签都被文案**包成子串**，
+     * 这一组断言（26 条 {@code contains}）就全过。F1 踩的正是这个坑：数组里「商户签约负责人」是
+     * 「商户签约负责人电话 / 邮箱」的前缀，把前者那条标签文案改掉时，后两条自己就把这个前缀带出来了
+     * （实测：把 production 里 contact_name 那条标签改成「签约负责人」，旧断言下本类 57 条全绿）。
+     * ★ 「一条是另一条的前缀」**不是** {@code contains} 唯一放过的一种 —— 它只是**这一类**里的一个成因：
+     * 凡是**改了标签文案、却让每个期望标签仍然原样留在文案里**的改动，这组断言都放过 —— 把某条
+     * **标签**改长（{@code 商户客服电话} → {@code 商户客服电话（座机或手机）}）或给它**加尾巴**
+     * 同样如此。换成「按顿号切回来、数量与集合都比」之后，这一类就都红了。
      *
      * <p>★ 切分这个判据的两个前提（改本数组或改文案构造时要一起看）：① 标签里不含顿号「、」
      * （用例里有断言，含了就红）；② 文案的构造是「进件必填项缺失（共 N 项）：」+
      * {@code String.join("、", labels)}（{@code LsyOnboardingService} 必填缺失那一支）。
+     * ★ 代价：这个判据对**文案外形的改变**会**假红，而且失败信息指错方向** —— 给清单加一句尾巴
+     * （例：{@code ……对私账户身份证反面照片。请补全后重试}）时 26 个标签一个不缺，红的却是
+     * 「标签清单必须与期望的 26 个逐字相同」；同族还有 {@code ）：} 后加空格（首项多一个前导空格）、
+     * 前缀改写引入**更早**的冒号（{@code labelsIn} 切在第一个「：」上，切出来的位置就变了）。
+     * 这是**取舍不是疏忽**：要让它对尾巴钝感，就得放弃「数量相等」这一半 —— 而「多一个」与
+     * 「26 个都在、另有一个重复」这两种恰好只有数量能抓（集合相等时它们仍然不同）。
      */
     private static final String[] MERCHANT_MICRO_MISSING_LABELS = {
             "商户名称",
@@ -1706,9 +1717,11 @@ class LsyOnboardingServiceTest {
      *   <li>★ **两个键都在、都是非空、且值不同** ⇒ 取到的是 {@code merchant_no} 那个。</li>
      * </ol>
      *
-     * <p>★★ 第 4 个子场景是**未决语义下的现状钉子**，不是设计决策：spec §6.2(c) 的立场是两个键
-     * **本该是同义别名**（返回参数表写一个、返回示例写另一个），正常只会有一个有值；
-     * 真出现「两个都有值且不同」时哪个算数**当前没有依据** —— 联调跑一次之前不猜。
+     * <p>★★ 第 4 个子场景是**未决语义下的现状钉子**，不是设计决策：spec §6.2(c) 说的**观察**是
+     * 「返回参数表写一个、返回示例写另一个」，它的**结论**是「创建成功后到底从哪个 key 取号，只有
+     * 真跑一次才知道」；「两个键**本该是同义别名**、正常只会有一个有值」是**我们的读法**（spec 里
+     * 没有这句），不是 spec 的立场。真出现「两个都有值且不同」时哪个算数**当前没有依据** ——
+     * 联调跑一次之前不猜。
      * 所以这里把**现状**（服务端 {@code createMerchant} 先读 {@code merchant_no}、空白才回落
      * {@code shoubei_merchant_no}）钉住：将来任何人改动那个优先级，这条断言都会红。
      * <b>语义裁定之后要改两处</b>：① 服务端取号那两行的先后；② 本用例第 4 个子场景的期望值