pool/multiplexed: synchronize initial connection setup

[qihai-coding]

A failed dial during connection initialization can modify the connection slice concurrently with initialization, or remove the node before the connection set is published. Construct the set first, then initialize and publish it under the existing connection-set mutex. Dialing remains asynchronous.

Expand the existing dial-failure test to cover TCP and UDP with the default, one, and four initial connections. Each case makes 100 attempts in the same pool and waits for cleanup before the next initialization.

Validation:

• The expanded test detects the race on the original implementation.
• Targeted race tests pass for 20 repetitions each with Go 1.19.13 and 1.27.2 on Linux.
• Go 1.19.13 connection-pool tests, build, and full main-module test suite pass.
• Formatting, diff checks, and incremental golangci-lint 1.64.8 pass. The linter uses Go 1.24.1 to load packages.

Fixes #251

RELEASE NOTES: Fix a data race when initial multiplexed connections fail to dial, and ensure failed connection sets are removed from the pool.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[qihai-coding]

I have read the CLA Document and I hereby sign the CLA

[liuzengh]

Reviewed 119a78a2de19953dbfb02174d94397a01914a7d4. This fixes #251: holding the connection-set mutex across both initialization and publication prevents the append/expel race and ensures failed-dial cleanup cannot run before Store. Dialing remains asynchronous, and the existing connection-reuse and expansion paths gain no additional lock operations. I found no new lock-order cycle.

Independent validation on Go 1.24.11, Linux/amd64:

• The expanded regression test passed with -race -count=20.
• The issue-style default-pool failed-dial reproducer passed 30,000 iterations with -race.
• Applying the expanded regression test to the pre-fix implementation reproduced the original data race.
• go test ./pool/... passed.

The broader go test -race ./pool/... run still reports races in the test TCP server's connection list and TestGetDialCtx's deep comparison of contexts. I reproduced both on base commit 56cbf53; they are pre-existing test issues, not regressions introduced here.

For performance, the additional mutex acquisition is per connection-set initialization, not per request. Local warm-path microbenchmarks showed unchanged allocation counts and no consistent slowdown. Longer cold-start benchmarks encountered loopback TCP dial timeouts, so they do not support a reliable cold-start latency or throughput claim.

No blocking findings. Approve.

---

已评审 119a78a2de19953dbfb02174d94397a01914a7d4。该修改解决了 #251：连接集合互斥锁同时覆盖初始化与发布，既避免 append 与 expel 并发修改切片，也保证拨号失败后的清理不会早于 Store。拨号仍然异步执行，已有连接复用和扩容路径没有新增锁操作；未发现新的锁顺序循环。

在 Go 1.24.11、Linux/amd64 上独立验证：

• 扩展后的回归测试以 -race -count=20 连续通过。
• 按 issue 方式构造的默认连接池拨号失败测试，在 -race 下累计 30,000 次循环通过。
• 将扩展后的回归测试用于修复前实现，可以复现原始数据竞争。
• go test ./pool/... 通过。

更大范围的 go test -race ./pool/... 仍报告测试 TCP server 连接列表、以及 TestGetDialCtx 深比较 context 时的竞态。这两项均已在基线 56cbf53 上复现，属于既有测试问题，并非本 PR 引入的回归。

性能方面，新增加锁发生在连接集合初始化时，而非每次请求。本地已有连接复用基准的分配次数不变，未观察到一致的性能下降。较长时间的冷启动基准遇到了 loopback TCP 拨号超时，因此不能据此给出可靠的冷启动延迟或吞吐变化结论。

未发现阻塞合并的问题，同意合入。

[liuzengh]

流水线 typo 问题已经在 #254 中修复，与本PR变更无关，同意合入