docs(进件): 交付说明订正 —— §六 那条「未封/不可达」是假话，§十 补 652 绿

只改文档，零代码变更（跑了一次全量 mvn clean test，未改任何生产码）。

起点是把交付说明当断言逐条对代码复核 —— 它是要交给用户做最终验收的器件，
而它自己写的「仍开着」同样是一份二手描述。

§六（标题就叫「仍然开着的窗口」）第 4 条原写「更新腿的 mass-assignment 口未封（R-7c）……
今天不可达（生产代码无调用方、无控制器绑定）⇒ 将来给更新腿开 HTTP 入口时必须加同样的封盖」。
判否：R-7c 早把那扇门开了，而封盖与门是同一次提交装的（实读 LeshouyingOnboardingController
:242 @PostMapping("/update") → :247 rejectBodySuppliedRateCode(…)；端点绑的
UpdateMerchantRequest extends LsyMerchantUpdateDTO :267）。
最刺眼的是同一份文件的 §七 早就写着「封盖与门一起装」，而 §六 还挂着「未封」—— 两条都是我写的。
验收者读 §六 会以为还有一个未处置的口子，方向有害。
已就地订正：原文逐字保留 + 删除线 + 读数，并点明「不是已修复的旧缺陷，是登记过的将来项、
现在到期并已处置」。

§十 的链子断在 647（R-7c 的 652 从没写进去）。本次自己跑全量，两支独立量法同值
（Maven 汇总行 Tests run: 652 / BUILD SUCCESS；49 个 surefire XML 聚合 tests=652、
failures/errors/skipped 各 0），并配了正控（每个 XML 确实带 tests= 属性 ⇒ 那个 652 不是
「0 个文件求和得 0」那一型假读数）。+5 定位到提交、不是推算：
git show 1af6ef2 -- '*/src/test/*' | grep -c '^+.*@Test' = 5；同法量 5290d84 = 2，
与 645→647 的 +2 对得上。

顺带复核（登记「我查过」）：§二 2.2 五跳引用（permission.store.ts:6/203/206/207、
UserService.java:623/636）逐行对得上；§四 4 引的两个台子文件都在，
task-9-fix1-harness.mjs 的 10796 B / sha16 7f07de4099c96a23 与件里写死的一致。

未删任何东西。

.claude/plan/2026-09-23-lsy-onboarding-B-交付说明.md

@@ -207,8 +207,20 @@
    （回 `Result.of(500, "处理未成功，请稍后重试")`）—— 但它是**控制器局部**的（类上是 `@RestController`，
    **不是** advice，见 `:266` 的注释解释了为何故意不用全局 advice）⇒ **只覆盖那 7 个 open API 端点**。
    修管理端时可照它的形状，**但文案要换成防重试口径**（open 侧那句「请稍后重试」在这里是有害的）。
-4. **更新腿的 mass-assignment 口未封（R-7c）** —— `LsyMerchantUpdateDTO` 带 `rateCode`，更新腿会用它覆盖平台费率。
-   **今天不可达**（生产代码无调用方、无控制器绑定）⇒ **将来给更新腿开 HTTP 入口时必须加同样的封盖**。
+4. ~~**更新腿的 mass-assignment 口未封（R-7c）**~~ —— **★★ 2026-09-23 已封盖**（提交 `1af6ef2`，
+   **与「开门」同一次提交**，不是先开一扇裸门）。原登记逐字保留：
+   「`LsyMerchantUpdateDTO` 带 `rateCode`，更新腿会用它覆盖平台费率。**今天不可达**（生产代码无调用方、
+   无控制器绑定）⇒ **将来给更新腿开 HTTP 入口时必须加同样的封盖**」—— 那个「将来」到了：
+   用户指示「把修改商户的入口开出来」。
+   **实测**（`LeshouyingOnboardingController`，逐行读；`:242` 就是那个新端点）：
+   `:242` `@PostMapping("/update")` → `:244` `requireTenantId()` → `:245` `requireByMchNoForTenant(…)`
+   → `:246` `rejectBodySuppliedTenantId(…)` → `:247` `rejectBodySuppliedRateCode(…)` → `:248` `updateMerchant(body)`。
+   （`rateCode` 字段在 `LsyMerchantUpdateDTO:199`；端点绑的是本控制器的内部子类
+   `UpdateMerchantRequest extends LsyMerchantUpdateDTO`，`:267` —— 即**同一条更新腿**。）
+   ★ 封盖是**实数上要装的**、不是理论洁癖：两向变异 **M-2** 摘掉 `rejectBodySuppliedRateCode` 后，
+   带 `rate_code` 的请求 `$.code` = **0**（一路走通）；顺序也被四条独立断言钉住（**M-3**：把
+   `updateMerchant` 提到闸之前 ⇒ **4 红**）。读数见工作区台账加记 87。
+   ⇒ 本条**不再是开着的窗口**。★ 也**不是**「一个已修复的旧缺陷」——它是**登记过的将来项，现在到期并已处置**。
 5. **409 文案拼入上游返回的 `mchNo` 原值**（该方法对自己的日志做了消毒、对这个 message 没有）—— 需上游返回**含换行**的商户号才成立；
    仓里已有同形先例。**裁定：不修**，届时随统一消毒一并处理。
 6. **一处「严格读不成立」的旧注释，裁定不修**（`LsyOnboardingService.java:363-365` 那句
@@ -358,6 +370,15 @@
   与 `areasEndpoint_upstreamCallFailure_saysRetryable_notTheWriteEndpointsAntiRetryCopy`）。
   ★ 上面那条「`@Test` 计数 **646**」是 **`2663020` 时点**用**另一支量具**（数注解）的读数，
   本轮**未**用同一支量具复量 ⇒ 不要把它与 647 相加或相减（两者量法不同，本件不替它推数）。
+- ★ **全量 `mvn clean test`：652 绿**（`Tests run: 652, Failures: 0, Errors: 0, Skipped: 0`、
+  `BUILD SUCCESS`、rc=0）。★ **本次是我在 2026-09-23 收尾轮自己跑的**，不是转述。
+  **两支独立量法同值**：① Maven 控制台汇总行；② `target/surefire-reports/*.xml` 逐文件聚合 ——
+  **49** 个报告文件、`tests` 合计 **652**、`failures` / `errors` / `skipped` 各 **0**。
+  ★ 配了**正控**：每个 XML 确实带 `tests=` 属性（逐个命中 1）⇒ 那个 652 **不是**
+  「0 个文件求和得 0」那一型假读数。
+  相对上面 647 的增量 **+5** 已**定位到提交**：`git show 1af6ef2 -- '*/src/test/*' | grep -c '^+.*@Test'`
+  = **5**（R-7c 的 `POST /update` 那组用例）；同法量 `5290d84`（R-7b）= **2**，与 645→647 的 +2 对得上。
+  ★ 上面 645 / 647 两行**保留不动** —— 它们是各自时点的真读数，本行只是把链子接到今天。
 - **两个注释修复提交 `70bb22a`、`2663020` 也都是 645 绿**（BUILD SUCCESS）。
   两者**「逐字节无行为变化」的完整证据**（`2663020` 这一版**两侧的 class 读数都是我自己采的**）：
   ① 行数不变（CR=1485 / LF=1485，无孤立 CR/LF，行尾仍 CRLF）⇒ `LineNumberTable` 不变；