Fix concurrent isolated-startup races (network create + ingress DNS latch)

[ChrisJBurns]

Summary

The E2E Tests Core (core) shard has been failing on almost every PR because several MCP workloads of the same image start concurrently (the group_rm / list_group specs) and hit a family of concurrent isolated-startup races. Diagnostics added in #6063 captured the actual Docker errors. There are three distinct bugs; #6069 fixed one, and this PR fixes the other two:

1. Shared-network create race (fixed here). Concurrently starting workloads share the toolhive-external network. createNetwork checks existence then creates in two non-atomic steps, so more than one caller races on NetworkCreate and all but one fails with network ... already exists → workload status "error". Fix: treat a NetworkCreate conflict as success (the network is already in the desired state).

2. Ingress port collision — fixed by Stop deriving the ingress proxy port from a fixed upstream port #6069 (FindOrUsePort(upstreamPort+1) → random), merged into this branch.

3. Ingress DNS latch (fixed here). After the port collision is fixed, a workload still gets stuck in status "starting" behind a persistent ingress 502, even though the MCP server is healthy and listening. The ingress Squid cache_peer targets the MCP container by name; under concurrent startup the container's Docker DNS record lags, Squid caches the failed lookup, and the peer never revives within the 2-minute readiness window. Ordering ingress creation after the MCP container (the existing mitigation) is not enough when DNS registration itself races. Fix: resolve the MCP container's IP and give it to the ingress proxy as the upstream address, so there is no DNS lookup to latch on — a transient failure becomes connection-refused, which Squid retries and recovers from in seconds. The Envoy backend's ingress cluster is pointed at the same IP for parity.

Together with #6069, this closes out all three concurrent-startup failure modes.

How this was found

Root-caused by reproducing each race directly: the network-create conflict fires 25/25 rounds under 8-way contention at the Docker API level (0/25 with the fix); the DNS latch was reproduced deterministically against a real Squid (upstream healthy + direct curl 200, yet Squid serves 502 HIER_NONE for 80s+), and a CI stress harness on the runner confirmed the status "error" (create/port) and status "starting" (DNS latch) signatures separately.

Type of change

• Bug fix

Test plan

• Unit tests (task test) — new real-daemon concurrency test for the network-create race (fails without the fix); pkg/container/docker package green including updated ingress-config and deploy tests asserting the ingress targets the MCP IP
• Manual testing — reproduced all three modes against a real daemon (Docker 29.4.3) and a CI stress harness on ubuntu-8cores

Does this introduce a user-facing change?

No. Concurrent workload startup that previously failed intermittently (failed to create external networks, or a workload stuck starting/error) now succeeds.

Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 34.48276% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.18%. Comparing base (a099fa0) to head (887a909).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/container/docker/client.go	22.22%	13 Missing and 1 partial ⚠️
pkg/container/docker/squid.go	28.57%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6071      +/-   ##
==========================================
- Coverage   72.20%   72.18%   -0.03%     
==========================================
  Files         721      721              
  Lines       75062    75085      +23     
==========================================
+ Hits        54198    54199       +1     
- Misses      17003    17021      +18     
- Partials     3861     3865       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.