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.

Empieza en tests/spike/clickhouse-client/clickhouse-containers.mjs, en attachDockerNetworkWithRollback (líneas 277-306) y startRow (líneas 419-422), y compara después su comportamiento de probePing con waitForReady. Comprueba spike-server.mjs:167-173 para ver el orden de arranque secuencial y reproduce el caso de inicio lento. Se considera terminado cuando el invariante de readiness documentado se cumple en el punto de llamada y la red del contenedor no se revierte silenciosamente durante el arranque en frío.