FileCacheStorage uses copy() instead of rename(), corrupting cache files on parallel cold-cache runs

Start with FileCacheStorage::save(), especially the temporary-file write and destination update, then inspect ParallelFileProcessor.php:181 to understand the reported worker failure. Reproduce with a removed cache directory and parallel processing, and verify that replacing the non-atomic cache update prevents truncated PHP files and the resulting parse errors.

Bug Report

On a cold cache, parallel runs intermittently abort with:

[ERROR] Could not process some files, due to:
        "Child process error: ".

and the worker JSON on the progress line carries bogus parse errors, varying per run:

{"fatal_errors":["syntax error, unexpected string content \"c343c467a1cdb4d496cd51fa46a79d...\""]}
{"fatal_errors":["Unclosed '(' on line 9"]}

Cause

FileCacheStorage::save() writes a temp file and then copies it over the destination:

FileSystem::write($tmpPath, sprintf("<?php declare(strict_types = 1);\n\nreturn %s;", $exported), null);
$copySuccess = @copy($tmpPath, $filePath);
@unlink($tmpPath);

copy() truncates the destination and streams into it, so it is not atomic. On a cold cache every
analysed file writes a cache entry while the parent process and the workers read those same files; a
reader that lands on a partially copied file loads a truncated PHP file and dies with a parse error
whose message depends on where the truncation falls. The worker's non-zero exit is then surfaced as
Child process error: with empty stderr (ParallelFileProcessor.php:181), which is why no file is
reported and the run fails at 100% with every file already processed.

Reproduction

3183 files, 32-core Linux, PHP 8.5.10, config using
->withCache(cacheDirectory: ..., cacheClass: FileCacheStorage::class):

Fix

Replacing

$copySuccess = @copy($tmpPath, $filePath);

with

$copySuccess = @\rename($tmpPath, $filePath);

fixes the issue