[ghshhf]

问题背景

用户手动用「其他设备端 → 自定义订阅」时，出网(egress)在中途死亡、但本地 socks 入站仍然应答的节点会表现为：能建立连接（能连接），但请求永远回不来（不能用），用着用着突然卡死。

根因（与早先判断不同，过完代码后发现是实时反馈缺失）：

• 节点的 Alive 健康位只由后台探针路径写入，实时请求的传输层失败（CodeTimeout/CodeTransport/CodeReset）只写入 3~60s 的 (exit,model) 封禁且按模型键控，节点的 Alive 从不随实时失败下调。
• 后台 ProbeDead 每 2 分钟只复查 !Alive 的节点；而 ProbeAll 约 30 分钟才一轮。于是死出口要等最长 ~30 分钟才会被发现。
• 期间每个走它的请求都先挂到 responseHeaderTimeout=90s 才超时 —— 这就是反复“能连接但不能用”的卡顿来源。

修复

把实时传输层失败反馈回节点级健康：

• 新增 Rotator.ReportDead(nodeID)：(exit,model) 之外新增节点级失败计数，在 failMemory 记忆窗口(10min)内连续 2 次传输层失败 → 节点 Alive=false。
• Alive=false 立刻让 Pick/nextNode 排除该节点，同时使其进入 ProbeDead 复查范围 —— 真死的出口一两个请求内离场，偶发卡顿的会在下一轮探针自愈。
• Revive（真实请求成功）重置失败计数并把 Alive 重新置 true（真实流量即活证）。
• 5xx(CodeServer) 与空 2xx 体(CodeEmpty) 视为连接已成功，不算出口死亡，只走 (exit,model) 封禁。

依赖

本 PR 建在 6c6b4e4 lane/gateway: split transport errors into reset / timeout / other（同分支内）之上 —— 只有把传输错误细分为 reset/timeout/other，才能精确触发本修复的降级逻辑。

测试

• internal/subs/ledger_test.go：新增 ReportDead 连续两次失败降级、failMemory 窗口外重置计数、Revive 重新拉起死节点。
• internal/lane/rotate_test.go：countRotator mock 补 ReportDead 以满足接口。
• go test ./internal/... 全绿。

关联

• 与早先的 PR fix(probe): 修正测速/能力实测的两类误判 #100（探测/能力探针判定修正）互补：fix(probe): 修正测速/能力实测的两类误判 #100 修的是「主动探测」结果被误判；本 PR 修的是「真实请求」失败没有回灌节点健康。
• 订阅「能连接不能用」现象直接相关。