clickhouse-containers.mjs: attachDockerNetworkWithRollback races container cold-start instead of confirmed readiness

Bắt đầu trong tests/spike/clickhouse-client/clickhouse-containers.mjs tại attachDockerNetworkWithRollback (dòng 277-306) và startRow (dòng 419-422), sau đó so sánh hành vi probePing của nó với waitForReady. Kiểm tra spike-server.mjs:167-173 để xem thứ tự khởi động tuần tự và tái hiện trường hợp khởi động chậm. Hoàn tất khi invariant readiness được ghi nhận là đúng tại vị trí gọi và network của container không bị rollback một cách âm thầm trong quá trình cold start.

attachDockerNetworkWithRollback's docstring in tests/spike/clickhouse-client/clickhouse-containers.mjs:292-297 claims the port was "confirmed reachable at container-boot time by the caller before this runs" — but startRow calls it at line 419 before waitForReady at line 422. Nothing confirms reachability before the attach runs.

The function's 4×1s probePing (lines 277-289, 306) therefore races ClickHouse's own cold start rather than checking an already-confirmed-live port. Found live and reproducibly (3/3 runs) during #585 Phase 0 WebKit-browser-matrix flake research: current-altinity-stable is consistently the row that loses this race and gets silently rolled back to default-bridge-only networking, because it's booted last (sequential boot order in spike-server.mjs:167-173) under maximum accumulated Docker load — so its cold start is slowest and most likely to still be starting when the probe fires.

This is comment/invariant drift (the docstring asserts a precondition the call site doesn't actually provide) that makes container network topology depend on relative boot speed rather than a real readiness check. Low urgency — this harness is dev/spike-only, not production — but worth fixing before the harness is relied on again for a rerun of the #585 browser matrix, since it's a plausible contributor to that matrix's one flaky cell (see #585 ship-log / ADR-0005 evidence discussion).

Suggested fix: either call attachDockerNetworkWithRollback only after waitForReady resolves (matching the docstring's own claimed precondition), or have the docstring/precondition match reality (loosen probePing's retry budget, or make it wait for the same readiness signal waitForReady uses).

Found by: automated root-cause research launched from a /ship-adjacent session, 2026-08-06.