fix: 使用 context 替代 closeChan 修复 processLoop 中 send on closed channel …

[caiwc]

…panic

子 goroutine（读消息、ping 超时）在 processLoop 退出后仍可能向已关闭的
closeChan 发送数据，导致 panic: send on closed channel。

使用 context.WithCancel 替代 closeChan 作为关闭信号机制，所有子 goroutine 通过 cancelLoop() 通知退出，主循环监听 loopCtx.Done()，彻底消除竞态。

Fixes: #27, #28, #32

[ViolaXJS]

求合并，同遇到这个问题

[typefield]

AI review出来的小问题,需要麻烦看卡 @caiwc

仍存在的小瑕疵（建议作者顺手修）
defer func() {
cancelLoop()
close(pongChan) // ← 这一行其实可以删掉
}()
cancelLoop() 已经让 PongHandler 走 <-loopCtx.Done() 分支返回，没人再读 pongChan，不需要再关闭。
而保留 close(pongChan) 反而留了一个理论窗口：cancelLoop() 调用完到 close(pongChan) 之间，若 PongHandler 恰好被触发，select 的两个 case 都 ready，Go 的 select 是伪随机选择的，仍有概率走到 send 分支并 panic（虽然非常窄）。
删掉这一行后，pongChan 由 GC 自然回收，逻辑更干净、也彻底没有残留竞态。

[caiwc]

AI review出来的小问题,需要麻烦看卡 @caiwc

仍存在的小瑕疵（建议作者顺手修） defer func() { cancelLoop() close(pongChan) // ← 这一行其实可以删掉 }() cancelLoop() 已经让 PongHandler 走 <-loopCtx.Done() 分支返回，没人再读 pongChan，不需要再关闭。 而保留 close(pongChan) 反而留了一个理论窗口：cancelLoop() 调用完到 close(pongChan) 之间，若 PongHandler 恰好被触发，select 的两个 case 都 ready，Go 的 select 是伪随机选择的，仍有概率走到 send 分支并 panic（虽然非常窄）。 删掉这一行后，pongChan 由 GC 自然回收，逻辑更干净、也彻底没有残留竞态。

@wqyenjoy 已处理，删掉了 close(pongChan)，这里确实不用关；同时补了个回归用例，覆盖 processLoop 退出后残留 PongHandler 被触发不 panic。提交在 c0fa0bc。

[typefield]

please give me your test case ，thanks for your pr @caiwc

[caiwc]

please give me your test case ，thanks for your pr @caiwc

测试用例已经补上了，这次主要覆盖了 processLoop 的几个退出路径，放在 client/client_test.go 里。

新增的几个 case 是：
TestDingtalkOpenStreamClient_processLoop_ReadErrorCancelsLoop
TestDingtalkOpenStreamClient_processLoop_PingTimeoutCancelsLoop
TestDingtalkOpenStreamClient_processLoop_PongHandlerAfterExitDoesNotPanic

分别对应：

1. 读协程报错后主循环能正常退出
2. ping 超时后能正常退出
3. processLoop 退出后残留 PongHandler 再被触发时不会 panic

这几个用例对应的是这次 PR 修的几个关闭路径问题。提交在 920212d。

[uouuou]

我提的都被关闭了，有朋友说官方不在意，只能自己做一个分支自己修复了，哎