python/config: make download_reactively race-safe under parallel exec…

[nilfm99]

…ution

download_reactively() invokes urllib.request.urlretrieve(remote_path, local_path) which writes incrementally to local_path. Concurrent processes that share the same fixture cache (e.g. pytest-xdist workers) check os.path.exists(local_path) and short-circuit, but between the moment urlretrieve creates the file and the moment it finishes writing, the file exists and is partial. A second worker that arrives in that window opens local_path, reads garbage, and proceeds. For YUV fixtures consumed by feature extractors, the visible failure is non-deterministic feature scores -- the same test produces different actuals on different runs.

Fix: download into a sibling tempfile via tempfile.mkstemp() then os.replace() onto local_path. os.replace() is atomic on POSIX, so concurrent writers can only ever overwrite a complete file with another complete file; readers never observe a partial file. The unique sibling name (mkstemp suffix) also prevents a second race between two workers writing to the same tempfile.

Behaviour preserved:

• same early-return when local_path already exists,
• same os.makedirs(parent, exist_ok=True),
• same urllib.error.HTTPError handling and re-raise.