sccache daemon inherits vcpkg lock fd from cmake

When cmake --preset runs, it spawns a vcpkg process that takes a filesystem lock on vcpkg_installed/vcpkg/vcpkg-running.lock. cmake also starts an sccache daemon (sccache --start-server) as a compiler wrapper. Because sccache inherits all open file descriptors from its parent cmake process, it holds the lock fd open long after vcpkg and cmake have exited. Any subsequent cmake --preset run then blocks on "waiting to take filesystem lock…" indefinitely. The workaround is sccache --stop-server, which closes the inherited fd and releases the lock.

This causes every repeated cmake --preset invocation to hang, appearing to be a vcpkg network or install problem. Developers waste time waiting or killing the process, not realising sccache is the culprit. The fix is to ensure the sccache server is started with FD_CLOEXEC on the lock (cmake side) or to close inherited fds before exec (sccache side), or to configure cmake to call sccache --stop-server after configure completes.

• Lock path: build/output/linux-clang-debug-make/vcpkg_installed/vcpkg/vcpkg-running.lock
• Workaround: sccache --stop-server
• Diagnosis: fuser <lock-path> identifies sccache (not vcpkg) as the holder