Prevent concurrent LFS downloads from corrupting archives

Summary:
Sandcastle getdeps jobs lack LFS records for the CMake 3.31.12 macOS archive and fall back to racing external downloads. Adding those records moves the jobs to LFS, but concurrent getdeps callers can still request the same cached archive. With a shared `<filename>.part` staging path, the first successful `os.replace()` removes the source path while another caller still expects to publish it, causing that caller to fail and potentially fall back to the unreliable external source.

Give every download a random sibling staging path, create it exclusively with the normal umask-derived permissions, hash the payload while streaming, and atomically replace the target only after verification. Independent staging paths let concurrent downloads publish safely. Exclusive creation avoids clobbering a colliding path without introducing `mkstemp()`'s owner-only mode, while cleanup after a failed replace prevents random `.part` files from accumulating.

Point both CMake archive names at the existing content-addressed Manifold object so Darwin getdeps jobs use the stable cached archive.

Reviewed By: genevievehelsel, clara-9

Differential Revision: D114722621

fbshipit-source-id: b9b9d56266b15ac1db3b5ea976d23159c0bb18c8

Author: Jose García Gimeno

build/fbcode_builder/manifests/cmake

@@ -23,7 +23,7 @@ sha256 = 0c4baa40f28b3f8225eb3fdf6946c987b4fe901403b4eaf2fbbd9378100aaa0c
 
 [download.os=darwin]
 url = https://github.com/Kitware/CMake/releases/download/v3.31.12/cmake-3.31.12-macos-universal.tar.gz
-sha256 = 7098ade6a0ecef2b6454f7389653fddcd7083f12cd5af181615b72d1743dc30f
+sha256 = 799af7fd545db9bf1b9cfe72f8095880e727a2d4e0df0e3dffc3bc7b95c2d3b0
 
 [download.any(os=linux,os=freebsd)]
 url = https://github.com/Kitware/CMake/releases/download/v3.31.12/cmake-3.31.12.tar.gz