Producer.reconnect() 会默默地丢弃无法重新匹配的接收器,永久中断它们的消费者

**修正, 2026-09-15。** 下面的分析将错误归因于两个 `continue`。在 WebRTC/Nest 部署中观察到的情况是,两者都无法触发: `webrtc.Conn.GetTrack` 在每个非崩溃分支中都返回一个空错误,而新的 Nest 会话则使用相同的 H264/Opus 多媒体,因此 `MatchCodec` 进行了相同的匹配。操作性的行是 **在 :222 处的 `break`** - `reconnect()` 最多只能匹配一个接收器/媒体。当 `p.receivers` 保持两个 H264 接收器(相同的媒体)时,即 #2389 状态(PT 96 接收器上的冷消费者和 PT 98 接收器上的热消费者),第二个从未被 `Replace()` 替换,并且通过 `p.conn.Stop()` 关闭。下面的证据部分证明了这一点,而不是 `continue` 路径:新连接具有 H264 多媒体,因此 `MatchCodec` 失败无法解释遗失的发送者。