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

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.

tests/spike/clickhouse-client/clickhouse-containers.mjs の attachDockerNetworkWithRollback（277-306 行）と startRow（419-422 行）から始め、probePing の動作を waitForReady と比較します。spike-server.mjs:167-173 で逐次的な起動順序を確認し、起動が遅いケースを再現します。完了の条件は、呼び出し箇所で文書化された readiness invariant が成立し、コールドスタート中にコンテナネットワークが暗黙にロールバックされないことです。