fix(lftpd): LIST/NLST 满块续发——大目录不再被静默截断并回 550

现象：`ftp_test.py` 的 `LIST 150->226` 断言失败——1512 B 数据全收到了，完成回包却是 **550**。

**根因**（`send_list`/`send_nlst` 各一处）：定案三把"整份目录一次性批量发送"落进 static 1536 B
缓冲时，顺手留下了"装满就 `break` 并回 −1"，`cmd_list` 据此回 550。于是目录一旦超过一块，客户端
拿到的是**静默截断**的清单**外加一个错误码**——而清单看起来完全像"目录里就这些"。这比单纯报错
更危险：没有人会去数条目个数。

**台架实测（同一台设备、同一个根目录，改动前后各测一次）**：
· 改前：1512 B / **24 条目** / 完成回包 **550**（停在 A0007.BIN，后面 6 个文件被吞）
· 改后：1880 B / **30 条目** / 完成回包 **226**

**修法：满块续发**，而不是把缓冲区加大。新增 `list_batch_flush()`——装满一块就整块发出、清空
继续装，收尾再发最后一块。为什么仍要"批量"：定案三的本体是实测结论——同一连接上背靠背 ~60 B
小段写会毒化 CH395F 的 TX（芯片报 SEND_OK 但对端全丢，无 RST 无 DISCONNECT），而 RETR 的 1 KB
满块连发安全；所以这里只发大块，绝不退回"每行一发"。单行真装不下时**明确失败**而不是少发条目
（8.3 短名 + 定长格式远小于 1536，真发生说明格式被改坏）。两条出口的 `lftpd_io_closedir` 收敛到
循环后单点：卷锁持有至 closedir，任何提前 return 都会漏锁。

**防回退**（关键）：修完之后，**目录清空的设备上这颗雷再也暴露不出来**，所以补了
`test/host/ftp_list_fill_test.py`——自造 26 个 8.3 短名文件把清单撑过一块，三条判据（STOR 全 226
／LIST 全文里每个名字都在／完成回包 226 而非 550，用 ftplib `retrlines` 让非 2xx 完成直接抛），
跑完逐个 DELE 还原。真机实测 `收到 56 行 / 3544 字节`（跨 3 块，满块续发被真正走到）→ 三条全
PASS。用法登记进 `docs/测试说明/FTP_Test_Guide.md` §4.5，机理与增补写进
`docs/问题记录/CH395F_Trap_Records.md` 定案三。

**顺带记录的已知偏差（未修）**：`cmd_list`/`cmd_nlst` 忽略命令参数、恒列会话 CWD
（`client->directory`）。主流客户端都是 `CWD` + 裸 `LIST`，实际影响小，先记在案。

体量：`Code` 213,264 → **213,436 B（+172）**、RO 不变 → `ER_IROM1` **232,088 B（22.1%）
  **、
`ROM 合计` 233,276 B；**RAM 一字未动**（`RW_IRAM1` 75,264 B 57.4% / `RW_CCM` 57,376 B
  87.9%）。
数字联动照做：`data/ram_report` 重跑、`ram_baseline --update/--write`、
  `check_mem_numbers --write`、
FLASH 配图常量重算重生成（桶合计 = 232,088 与 `Code+RO` 相符）、报告 §1.3/§5.1/§5.4 与部署 §3.3。

门禁：`@build` 0 错 0 警告；`@test` PASS（692 ms）；`ftp_test.py` → **TEST
  PASSED**（含此前失败
的 `LIST 150->226`）；`ftp_up_dl_test.py` → TEST PASSED；`ftp_list_fill_test.py`
  → TEST PASSED；
`doc-links --all` 146 文档 0 问题；`id-check --strict` 增量拦截通过（可判定 82.82%）；
`mem-numbers` / `mem-budget` 通过；改动文件字节卫生 BOM 无 / CR 0 / U+FFFD 0 / 无行尾空格。未推送。

docs/问题记录/CH395F_Trap_Records.md

@@ -132,7 +132,7 @@ CH395F 以太网驱动与 NET 层的实证陷阱：现象、定案根因、修
   2. **幽灵态甄别**：补 accept 前回读对端端口（`GET_REMOT_IPP`），**= 上一条连接端口（`last_peer_port`）→ 幽灵，不 accept**；
   3. 对账②同步加幽灵甄别；`last_peer_port` 登记点：`handle_disconnect_event` / `handle_timeout_event` / `net_relisten_try`（清零 remote_port 前转登）/ `net_close_locked`（跨 memset 保留——幽灵属芯片 Socket 级，与 fd 复用无关）。
 - **定案二：closed-with-data accept（425 真根因=accept 竞态自毁缓冲）**：`FUN_PARA` bit3 `SOCKET_CLOSE=1`（§5.52 ②）下产生 DISCONNECT 后芯片**不关 Socket、不清缓冲**，RX 缓冲里 STOR 载荷一个不少（探针实证 `recv_len=1027 re-read st=0x05/0x00`）；那个 DISCONNECT 是**客户端正常 FIN**（ftplib `storbinary` 发完即关，局域网小文件 ~5ms）。旧 `net_accept_locked` 把 CLOSED 一律当"无连接" → `net_relisten_try`（close+open **清空芯片 RX 缓冲**）→ 数据被**我方亲手销毁** → 425。**修复**：CLOSED + auto_relisten + **芯片 RX 有数据**（`GET_RECV_LEN_SN`>0）→ 接受这条"已关但可读"连接（日志 `closed-with-data accept (drain pending)`），应用快路径排空，排空后 EOF 自然触发 relisten——对齐 §5.52 ② 契约。
-- **定案三：LIST 吞包 = 背靠背小段写毒化芯片 TX**：决定性对照——同一目录，LIST #1（行间天然间隔）通过；LIST #4/#7（每行一次 `net_send` ~60B 背靠背小段）必挂。芯片对同一连接的**背靠背多段小写入**会毒化 TX（芯片报 SEND_OK 但对端全部丢弃，无 RST 无 DISCONNECT）；RETR 1KB 满块连发不受影响。**修复**：`send_list`/`send_nlst` 整份目录**一次性批量发送**（static 1536B 缓冲；注意 `lftpd_inet_write` 成功返回**字节数**非 0）。
+- **定案三：LIST 吞包 = 背靠背小段写毒化芯片 TX**：决定性对照——同一目录，LIST #1（行间天然间隔）通过；LIST #4/#7（每行一次 `net_send` ~60B 背靠背小段）必挂。芯片对同一连接的**背靠背多段小写入**会毒化 TX（芯片报 SEND_OK 但对端全部丢弃，无 RST 无 DISCONNECT）；RETR 1KB 满块连发不受影响。**修复**：`send_list`/`send_nlst` 整份目录**一次性批量发送**（static 1536B 缓冲；注意 `lftpd_inet_write` 成功返回**字节数**非 0）。 **2026-10-22 增补（同一处缓冲埋的第二颗雷）**：批量发送把"装满就 `break` + 回 −1"留在了路径上，`cmd_list` 据此回 **550**——目录一旦超过 1536 B，客户端拿到的是**静默截断**的清单**外加一个错误码**，而清单看起来完全像"目录里就这些"。实测台架根目录 30 条目：修复前 1512 B / 24 条目 / 完成回包 550，修复后 1880 B / 30 条目 / 226，**6 个文件凭空消失**。改成**满块续发**（装满一块整块发出、清空再装）：既保住"只发大块"这条实测结论（定案三的本体），又不让清单完整性由一个缓冲区上限决定；单行真装不下时**明确失败**而不是少发条目。同一函数还有个已知偏差：`cmd_list`/`cmd_nlst` 忽略命令参数、恒列 `client->directory`（会话 CWD）——主流客户端都是 `CWD` + 裸 `LIST`，暂未修，登记在案。 **回归**：`test/host/ftp_list_fill_test.py`（自造 26 个 8.3 短名文件把清单撑过一块，判"全列出 + 完成回包 226"，跑完自动删干净；用法见 `../测试说明/FTP_Test_Guide.md` §4.5）——设备目录清空后，只有这种自己造规模的脚本才拦得住这颗雷。
 - **与 TRAP-NET-17 的关系**：周期对账对常驻监听器有效；FTP 数据通道是"活 1 秒就死"的短命监听器，对账②无幽灵甄别时既救不全又帮凶。本条把"看状态补 accept"内联进 accept 热路径（短去抖、无冷却）+ 端口甄别，对账②保留为兜底网。
 - **教训（总纲）**：**CH395F 的"成功"（中断位/状态码）只代表芯片本地动作完成，不代表对端收到；判定必须回到对端可见证据（主机侧收发）+ 手册语义（FUN_PARA §5.52、状态码 §5.22）**。
 - **对应文件**：`net_events.c`（`net_lost_connect_probe` / `net_reconcile_tick`②；原在 `net_socket.c`，2026-10-14 抽出）、`net_socket.c`（closed-with-data accept）、`net_types.h`（`last_peer_port`）、`lftpd.c`（批量发送）；台架 `test/board/ch395f_reuse_bench.{c,h}` + `test/host/ch395f_reuse_host.py`（主分支存档）。