Flaky: ProbeVendorsConcurrently_SlowVendorMapsToTimeout_FastVendorsStillResolve under full-suite load #911

Problem

ProbeVendorsConcurrently_SlowVendorMapsToTimeout_FastVendorsStillResolve (in test/Capacitor.Cli.Daemon.Tests.Unit) fails intermittently on CI under full-suite load, then passes on re-run and in isolation — a timing flake, not a regression.

Evidence

• Failure: AssertionException: Expected to be greater than or equal to 2, because a sequential pass would never show two probes in flight at once.
• Observed on the macOS Build and test leg of unrelated PRs (e.g. Show harness and model as coloured chips in the session rail #904, Allow uncapped hosted agents with max_agents=0 #908) whose changes don't touch vendor probing; cleared on re-run.
• Confirmed locally: fails once in a full Capacitor.Cli.Daemon.Tests.Unit run, passes when run in isolation (--treenode-filter "/*/*/*/ProbeVendorsConcurrently_SlowVendorMapsToTimeout_FastVendorsStillResolve").

The assertion depends on observing ≥2 concurrent probes "in flight"; under full-suite CPU contention the probes evidently don't overlap in the observed window, so the concurrency assertion misses.

Likely fix direction

Make the concurrency observable deterministic rather than timing-dependent — e.g. gate the probes on a barrier/TaskCompletionSource so the test controls when each is "in flight" instead of relying on wall-clock overlap under load. (Pattern precedent: other timing-sensitive suites here inject a controllable clock / gate rather than sleeping.)

Related flake symptoms seen in the same CI window (separate issues, noted for context)

• Daemon suite native crash: UnixSpawnerThread terminated unexpectedly / Process terminated (exit 139) tearing down a run — a PTY-spawner teardown flake.
• TimeoutException on Build and test (ubuntu) and a Timed out waiting for: established on retry connection flake (windows) under load.

These are listed only so the triager sees the broader picture; this issue tracks the ProbeVendorsConcurrently… flake specifically.