docs(N34): 阶段3 文档同步——reconciler 合并口径+net_drop_conn+Trap 补充

- BSD_Socket_API_使用指南：五层自愈→四层（合一 reconciler 形态①~⑤+U11，
  分级去抖②1/③④⑤2/①4轮+1s冷却）；新增 net_drop_conn 小节（拆会话保
  监听/幂等/EOF 不得调）；变更记录追加 2026-10-13 行
- BSD_Socket_API_函数调用关系：pump 节点删除、net_drop_conn 链路新增、
  驱动接口表补 sock_reset/cmd_done/缓存行、常量清单更正
- 网络Socket监听生命周期设计说明：新增 §10.10 合并说明，历史文本保留+注记
- Net层阻塞模型架构设计：主循环 3 tick 口径 + 附录 B 追加
- RAM使用分析与优化方案：netTask 链尾改 retry_tick→relisten（1944 B 不变）
- CH395F_Trap_Records：Trap 07 补充（close 无 RST：对端内核存活不 close
  → FIN_WAIT_2 长尾，兜底 E13）；Trap 09 补充（LISTEN 态二段关闭）
- 实施方案 §5：项1/2/3/5 ✅、项4 受 E6 暂缓、§5.1 E-02 收口、§5.2 延后项
- 实验方案：E-02 收口台架小节（FIN_WAIT_2/TIME_WAIT ~150ms/双 PASS）
- N34 README 裁决行更正；Test_Guide TC-NET-1101 pump→reconciler 形态③④

历史变更记录与历史事故描述一律原文保留、只追加；check_doc_links
--sections-strict 对改动文件 0 问题；乱码 0、无 BOM 变化。

docs/问题记录/CH395F_Trap_Records.md

@@ -181,6 +181,15 @@ Phase 2 测试，2025-07
 
 **与 Trap 17 的张力已消解**：Trap 17 写"close 后芯片要等对端 FIN/ACK 才把 Socket 置 CLOSED（耗时数毫秒）"，与本条原"close 发 RST 瞬间回 CLOSED"矛盾；实测支持 Trap 17 一侧（A 模式可见 `TIME_WAIT` 过渡、0~150 ms），不支持 RST 说法。
 
+### 补充（2026-10-13，E-02 台架）：`close` 无 RST 的**边界**——对端内核存活时芯片停 `FIN_WAIT_2` 长尾
+
+上条定案（"`close` 无 RST 语义"）在 E-02 收口实验里暴露出一个必须登记的边界，**不推翻定案、补全其适用条件**：
+
+- **对端配合**（收到 FIN 后其内核 close）：芯片走 `TIME_WAIT` 过渡 ~150 ms → byte0 回 `00H`，reconciler 形态④ relisten → 新连接接入（`e02_probe` 更新后 queue=PASS / listener=PASS，对时"wall clock updated"落地）。
+- **对端内核存活但不 close**（挂起但连接仍活的客户端）：本层发 FIN 后芯片停在 **`FIN_WAIT_2`（实测 byte0=0x05 / byte1=0x06）长尾**——没有 RST 就拆不掉，**监听恢复受限于对端 close**。这正是 E-02 场景（timeSync 30s 预算耗尽后 PC 侧 socket 仍活）的芯片侧形态。
+- **不配合场景的兜底** = 芯片自身 TIMEOUT / KeepAlive 拆僵尸会话（E13 定案：判死窗 30~90s，见 `docs/网络/N34-自愈审计/实验方案.md` E13）——**不是**应用可以加速的路径。
+- **应用侧出口 = `net_drop_conn(fd)`**（N34 阶段 3，E-02 收口）：netTask 侧走驱动 `sock_reset` **QUARANTINE**（FIN + 排渣 + 排空事件 + 等 byte0=00H，400ms 底）+ 本层收口 CLOSED + `auto_relisten` 即时重监听；**保监听不毁**（单连接模型不得 `net_close` 监听 fd）。对端不 close 时复位机等在 `net_poll` 步进里（`ch395f_sock_reset_poll`），对端 FIN 到达即自动走完——**不搁浅**。
+
 ### 发现时间
 Phase 2 TCP Client 测试，2025-07（**日期有误**，实为 2026-07-19；定案更正与 TC-NET-204 实测 2026-10-11）
 
@@ -289,6 +298,16 @@ CH395F 的 PHY link up 后，内部 TCP/IP 协议栈需要额外时间完成初
 - 此问题在单连接模式 (`FUN_PARA=0x00`) 和多连接模式 (`0x02`) 下均存在，与 FUN_PARA 无关
 - 如果多个应用任务同时启动 listen，可能全部首次失败、全部重试成功——建议各任务错峰启动
 
+### 补充（2026-10-13，E2 台架）：LISTEN 态 Socket 的**二段关闭**——一次 CLOSE 只拆监听，二次 CLOSE 才回 CLOSED
+
+E2/E4 芯片实验（`docs/网络/N34-自愈审计/实验方案.md`）补充发现，属本条"close 后需沉降才能重开"的**前置形态**：
+
+- 对处于 **LISTEN**（byte0=`05H` / byte1=`01H`）的 Socket 发 `CLOSE_SOCKET`：命令返 **SUCCESS**，但芯片**只拆监听**（byte1 `01H→00H`），**byte0 恒 `05H`**——单次 CLOSE 后按"等 byte0=00H"的判据会永远等不到。
+- **第二次 CLOSE** 才把 byte0 拉到 `00H`（Socket 关闭）。即 LISTEN 态的关闭是**两段**：拆监听 → 关 Socket。
+- **驱动侧已内置补发**：`ch395f_sock_reset_*` 状态机的 `WAIT_CLOSE` 段检测到"TCP 已 00H 而 byte0 仍 05H"自动补发第二次 CLOSE（契约见 `Drivers/BSP/CH395F/ch395f.h`）。
+- **生产路径由 Trap 09 的 open 重试环吸收**：`net_listen_locked` / `net_connect_locked` open 失败 → `net_sock_reset_sync`（确定性排渣，内置二段 CLOSE）→ 下一轮重试 open；E4 定案 60 轮实证"复位后 open 必成"。
+- ⚠ 任何**新写的**"close 后等 CLOSED"逻辑都必须走驱动复位原语，**不要**手拼"一次 CLOSE + 轮询 byte0"——那会在 LISTEN 态上死等（本条补充的直接动因）。
+
 ---
 
 ## Trap 10：消息队列值拷贝导致结果无法回传