refactor(net): 挂起 recv 模型拆出 net_pending.c/h + 留痕探针编译门控 + E15 归因修正

- E15 归因修正：幽灵状态 0x04+旧端口 = 芯片如实报告拆除中的旧连接
  （文档化行为，非芯片故障；bit3=1 为我方设置（ver>=0x46）、
  RFC 9293 §3.3.2 Fig5 拆除顺序、WCH 官方博客方案 = close 完成后重开监听）
- 术语统一：全库"了结"→"结束"（约 45 处）；阻塞模型 §4 首次出现处定义"五路"
- 注释清理：删孤儿函数头注释、考古叙事改现在时、去不可检索内部编码"L3"
  （33 处 6 文件）、banner 去重（唯一理由移到分支现场）
- 挂起超时留痕探针：编译期开关 NET_PENDING_TRIPWIRE（默认 0 = 编译剔除，
  省约 150B Flash；排查调用方挂死时置 1，只留痕绝不强制结束）
- 拆模块：net_pending.c/h（363/94 行）承载挂起 recv 模型，
  net_socket.c 4059→3661 行；tick 收控制块表参数、settle_close 双参显式传；
  net_pending_active 声明移配对头（S17 2.2）；仅注册 uvprojx +
  check_registration MCU-only 白名单（同 net_listener.c 机制，
  模拟器走 net_socket_sim.c 按外部语义模拟）
- 文档：阻塞模型新增全过程小节（单主干流程图）+ §9 排查辅助；
  NET README / 函数调用关系 / 自愈架构 / BSD 指南同步；引用关系图重生成
- 台架回归：启动闭环 PASS（[ERR]/Fault 零命中、回读一致）、
  :7003 重连探针 10/10、FTP 50 连接 STOR 50/50、回归窗口串口日志无异常
- RAM：ER_IROM1 230004B（探针门控后约 -150B），台账已回填

docs/问题记录/CH395F_Trap_Records.md

@@ -124,7 +124,8 @@ CH395F 以太网驱动与 NET 层的实证陷阱：现象、定案根因、修
 - **状态**：✅（回归 4 轮 11/11；全局寄存器读即清见第六章 B3）
 - **现象**：同一会话内**第 2 次及以后**的数据连接（LIST/STOR/RETR）两类失败，概率随上一条数据连接的负载与间隔变化：① **吞数据**——新连接建立成功、服务端 `net_send` 返回成功，客户端 20s 收不到任何字节；② **425**——新连接被接受后 ~10-20ms 出现 DISCONNECT（`chip tcp=0x00`），accept 失败。
 - **定案实验（裸机芯片台架，剥离 OS/net/FTP）**：`test/board/ch395f_reuse_bench.c` 内核启动前直接调 `ch395f_*` 受控矩阵 + 主机侧 `test/host/ch395f_reuse_host.py`。**剥离后 bug 依旧复现** → 纯芯片操作时序问题。关键现场：`post-listen st=0x05/0x04`（listen 成功但 TCP 态停在旧连接 ESTABLISHED=幽灵态）、`unexpected int=0x10`（只等来旧连接滞后 DISCONNECT）、`no CONNECT within 10s`（芯片状态已 0x04 但事件始终未到等待环——E14 复核：事件已被 drain 读清消费，非芯片丢失）。
-- **芯片级规律**：CH395F 拆链收尾窗口**变长且不可观测**（状态显示 CLOSED 持续 1s+ 也不代表拆完，实测可 >2s 且时长不定）。窗口内重新 `open+listen` 三种形态：① 握手完成但 **CONNECT 事件未收到**（E14 复核：事件被台架 post-listen drain 或读清竞态吞掉，非芯片侧丢失）→ 吞数据；② 状态直接假报 0x04 幽灵态（回读对端端口=旧连接端口）；③ 旧连接滞后 DISCONNECT 打到新监听 → relisten 毁掉新连接 → 425。
+- **芯片级规律**：CH395F 拆链收尾窗口**变长且不可观测**（状态显示 CLOSED 持续 1s+ 也不代表拆完，实测可 >2s 且时长不定）。窗口内重新 `open+listen` 三种形态：① 握手完成但 **CONNECT 事件未收到**（E14 复核：事件被台架 post-listen drain 或读清竞态吞掉，非芯片侧丢失）→ 吞数据；② 状态显示 0x04 幽灵态——旧连接拆链进行中，状态如实如此（E15 见下条；回读对端端口=旧连接端口）；③ 旧连接滞后 DISCONNECT 打到新监听 → relisten 毁掉新连接 → 425。
+- **归因更正（E15，2026-10-14，官方出处）**：旧"芯片谎报 0x04"措辞推翻——芯片**如实报告旧连接拆链进行中**：① `FUN_PARA` bit3 `SOCKET_CLOSE=1` 为我方设置（`net_init` 版本门控 ≥0x46；§5.52②/§5.23：DISCONNECT/TIM_OUT 后芯片**按设计不动 Socket 状态与缓冲**，等 MCU 关闭——"保留现场"是自家配置的文档化行为）；② 拆链走 TCP/IP 协议状态机（RFC 9293 §3.3.2 图 5；芯片状态码表见手册 §5.22，明言"其他状态芯片会自动处理并更新"）：主动关闭 FIN_WAIT_1→FIN_WAIT_2→TIME_WAIT（对端同时关经 CLOSING、同时关闭直达），TIME_WAIT 驻留 2MSL 才落 CLOSED——这就是拆链窗；TIME_WAIT 的协议目的即"防旧连接迟到报文影响新连接"（RFC 9293 §3.3.2），正是"断连即重连被拒"的协议层根源。重传默认 12 次（§5.17），实测重传耗尽 ≥3s（`test/board/ch395f_test_task.c` 超时分类实测）——与拆链窗实测 >2s 同量级；③ WCH 官方博客（《【WCH以太网接口系列芯片---CH395】CH395 TCP Server模式下客户端重连设置》，cnblogs sw111/18451802）明言"客户端主动断连并立即重新发起连接请求，此时 CH395 会拒绝该连接请求，因此需要程序中做一些特殊处理"，官方方案 = 关闭完成后再 open+listen——即我们的 settle/quarantine 等待；幽灵甄别是"强制放行"路径的护栏（防把拆链中的连接当新连接 accept）。状态面从来是真——I3 就此加强。
 - **已证伪的修复**（受控实验全部无效，列出防重踩）：close 后固定沉降 100~3000ms / Socket 轮换（跨 socket 毒化）/ listen 后 close+重试 / 缓冲重分配 / close 前 TX 排空延时 / 禁用对账 tick（对账不是元凶）。
 - **定案一：双信源原则——中断只是快路径，状态寄存器才是真相**：
   1. **accept 路径内联探针**（`net_lost_connect_probe`，`net_accept_locked` 每 100ms 挂探针）：芯片已 ESTABLISHED 而 CONNECT 事件未到 → 连续 2 轮去抖后补 accept；
@@ -187,7 +188,7 @@ CH395F 以太网驱动与 NET 层的实证陷阱：现象、定案根因、修
 - **修复（三阶段，`net_socket.c` + `lftpd.c`）**：
   1. **异常释放（TIMEOUT/RST）隔离**：`handle_timeout_event` 置 per-fd 隔离标记；`net_relisten_locked` 隔离期内持续排空芯片 RX（`net_drain_chip_rx()`）+ 主动 close + 排空该 socket 中断 + 等 `CLOSED/TCP_CLOSED`，满 `NET_RELISTEN_QUARANTINE_MS`(400ms) 才 open+listen；上限 `NET_RELISTEN_SETTLE_MS`(800ms) 强制放行——**必须小于** `NET_RELISTEN_DEADLINE_MS`(2000ms)：取 2000ms 会耗尽重试预算 → give up → **监听器死亡**；
   2. **正常释放（FIN）沉降**：`handle_disconnect_event` 登记（仅 `recv_bytes != 0` 时——纯连接即关与只发不收免沉降保复连时序），relisten 前最短等 `NET_RELISTEN_GRACEFUL_MS`(**100ms**，实测悬崖：0/30ms 无效、100ms 稳定通过)；日志区分 `relisten settle`/`relisten quarantine`；
-  3. **应用侧硬化**：`net_sock_t.released_abnormal` 标记（TIMEOUT 置 1/DISCONNECT 置 0，新 fd 与新监听清零——新连接不得继承上一条的释放原因）；`net_pending_tick` 断连了结按标记以 `NET_ERR_CONNRESET` 或 EOF(0) 回传；`lftpd receive_file` 错误路径 **unlink 截断文件** + STOR 回 **450**。
+  3. **应用侧硬化**：`net_sock_t.released_abnormal` 标记（TIMEOUT 置 1/DISCONNECT 置 0，新 fd 与新监听清零——新连接不得继承上一条的释放原因）；`net_pending_tick` 断连结束时按标记以 `NET_ERR_CONNRESET` 或 EOF(0) 回传；`lftpd receive_file` 错误路径 **unlink 截断文件** + STOR 回 **450**。
 - **协议边界（不可判定，留痕）**：FTP STOR 无长度声明，"在途 FIN 关闭"与"正常完成"**逐字节不可区分** → 优雅中止仍回 226；仅 RST/掉链（芯片 TIMEOUT）可识别 → 450。FIN 边界由客户端长度校验（SIZE/RETR 往返）兜底。
 - **回归基线**：`--check-abort` RST **5/5**（450）+ FIN **5/5**（226 边界不变）；followup 全过；正常往返 freeze SHA-256 全 MATCH；`:7003` sink 复用 RST×4/FIN×4 全过；`:8888` 真实收包写 RTC 成功。
 - **与 TC-NET-604 的关系**：本条是独立、已可信复现并已修复的真实缺陷；TC-NET-604 已结案为非缺陷（判读教训见第六章台架纪律）。现场"上传失败/文件不完整/像卡死"类报告优先用本条判据复核。