Fix build-processing jobs corrupting each other’s downloaded archive in a race

Fixes a race condition where two concurrent build-processing jobs for the same build could corrupt each other’s downloaded archive. Previously both jobs wrote the build zip to /tmp/build_<build_id>.zip, so one job’s download or cleanup could overwrite or delete the file the other was still unpacking, causing a spurious “doesn’t seem like a valid SLF line” parse failure even though the archive in storage was valid. The temp download path is now keyed on a per-execution unique integer as well, so concurrent jobs for the same build never share a file.