Fix flaky TestTCPCollectingProcess_ConcurrentClient

[antoninbas]

TestTCPCollectingProcess_ConcurrentClient fails intermittently in CI on main, e.g.:

--- FAIL: TestTCPCollectingProcess_ConcurrentClient (0.10s)
    process_test.go:352: Cannot establish connection to 127.0.0.1:36861

Cause

The test stopped the collector from inside one of the client goroutines, as soon as that goroutine observed at least 2 sessions. Nothing guaranteed that the other client had connected by then, so the listener could be closed before the other client dialed.

The session count is not a reliable signal for this: waitForCollectorReady dials the collector to probe for readiness, and for TCP that probe connection is itself registered as a session by the accept loop, and is only unregistered asynchronously after it is closed. Both goroutines run a probe, so the >= 2 condition could be satisfied by the two probe connections alone, before either client had connected.

Changes

Split into two commits:

1. Fix the flake. Stop the collector when the test returns, once all clients are known to be connected, rather than from a client goroutine. The clients still connect concurrently, which is the point of the test. The connections are also kept open and referenced until the end of the test — they used to be discarded immediately, allowing the garbage collector to close them at any point.

2. Stop dialing the collector in waitForCollectorReady. Both the TCP and UDP code paths bind the socket before publishing the collector's address, so waiting for that address is sufficient and has no side effect on the collector. For UDP the old probe never proved anything anyway, since dialing a UDP socket is a purely local operation. With the interference gone, the test now asserts that the collector has a session for each client and no other session, instead of asserting on the count only.

Testing

• Reproduced the original failure with the exact CI message by stressing the pre-fix test under scheduling pressure (-race -cpu=1, parallel runs).
• The fixed test passes 900 runs under the same conditions; the whole package passes 120 runs.
• Verified the new assertion is falsifiable: with a deliberately introduced regression that registers sessions under the wrong key, the new assertion fails while the previous count-based one passes.
• go test -race ./... and go vet -tags integration ./... are clean.

As a side effect, the tests get faster, since waitForCollectorReady no longer imposes a 100ms minimum delay at each of its 17 call sites. Locally, over 5 runs of go test -race ./pkg/collector/, the reported test time goes from 3.78-4.27s on main to 2.16-2.27s. The full unit suite (go test -race ./...) goes from 6.08-6.28s to 5.77-5.88s wall time over 3 runs.

Note: pkg/test/collector_intermediate_test.go has its own copy of waitForCollectorReady with the same probe-dial pattern. It is left untouched here, as no test in that package asserts on the collector's sessions.