test: [P2] RapidServerInitiatedReconnects 在持续负载的三目标顺序执行下间歇真实楔死（main 既有） #97

现象

ReconnectWedgeTests.RapidServerInitiatedReconnects_PortStaysAcceptable 在本机（Win10 22H2，i5-12500H）三目标顺序执行（dotnet test StreamFrame.slnx，net10→net8→net48 连续）且机器已持续高负载运行一段时间后，间歇性失败：

• 失败形态：WaitConnectedAsync 全预算挂起（10s 预算时代 12–16s 失败；PR fix: 被取代接受循环的杂音 Connecting 与迟到接入语义定稿（#68 PR-3） #96 已把该处预算对齐 30s 后出现 31–32s 全预算挂起）——真实楔死，非慢收敛：客户端 TCP connect 成功、服务端停在 Connecting。
• 频率：约 10–20% 的 TFM-run（net8/net10 均出现，net48 从未）。
• 不出现于：单 TFM 单跑、同类组合跑、CI（ubuntu + windows 矩阵，含 fix: 状态机停机竞速守门与回调重入会话撕裂修复 + 行为基线（#68 PR-1） #94/refactor: 会话资源收敛为内部 Session 对象 + 拆除分段（#68 PR-2） #95/fix: 被取代接受循环的杂音 Connecting 与迟到接入语义定稿（#68 PR-3） #96 多次全绿）。

已排除

• 非 refactor: [P2] 收敛连接状态转换与会话资源所有权，降低重连和停机竞态维护成本 #68 三个 PR 引入：干净 main（fb94cab）同样复现（1/9 TFM-run，12s 挂起）；PR-3 源码完全回退后亦复现。PR-3 调试期间曾以 4/4 连红误导为回归，实为本机状态依赖的既有问题被持续负载放大。
• 曾短暂引入"被取代循环迟到 accept 当场释放"实现：该实现会让此测试确定性失败（真实客户端被重置吞掉），已回退——与本 issue 的间歇形态不同，但说明该测试对"客户端接入被吞"敏感，可作调查探针。

调查方向建议

1. 楔死意味着客户端 SYN 落在了某个无循环 accept 的监听 socket 上（TCP 层完成握手、无人消费）。怀疑重点：SO_REUSEADDR 在 Windows 上的语义允许同端口双 bind——若新旧监听器短暂并存（重绑窗口），连接可能落到孤儿监听器的 backlog。需要端口级取证（netstat/Get-NetTCPConnection 快照 + 楔死瞬间抓取）。
2. 复现配方：本机连续跑三目标全套 ×N 轮预热机器状态后命中率上升；可脚本化复现 + 楔死时 dump _server/_acceptLoopId/_acceptLock 状态（白盒）定位是"双监听器"还是"循环全退"。
3. 若确认 Windows 双 bind 语义问题：InitServer 可改用 ExclusiveAddressUse + 受控重绑窗口，或 bind 后校验唯一性。

关联

• bug: 用户显式 Reconnect() 与自动重连竞速可长期楔死被动端监听（重绑失败 + 接受循环持有锁重试） #47（该测试的来源与代次门控设计）、fix: 被取代接受循环的杂音 Connecting 与迟到接入语义定稿（#68 PR-3） #96（预算对齐与迟到接入语义定稿的 PR 描述里有完整取证记录）、refactor: [P2] 收敛连接状态转换与会话资源所有权，降低重连和停机竞态维护成本 #68（DESIGN 已知限制/竞速语义章节）。