Stop the second vcpkg racing the first one's exit

[cb1kenobi]

⊙ Problem

linux-x64-glibc failed in run 37985294418, 1.4 seconds into Build RocksDB:

=== Removing any previously installed RocksDB ===
The following packages are not installed: rocksdb:x64-linux
=== Installing RocksDB (PerfContext enabled) ===
vcpkg-running.lock: note: waiting to take filesystem lock...
vcpkg-running.lock: error: failed to take lock, another vcpkg may be running against the same directory

The vcpkg remove #27 added has nothing to do on a fresh clone, so it returns in milliseconds; vcpkg forks a telemetry uploader as it exits, that child inherits the lock on the installed tree, and the install behind it reports a concurrent vcpkg rather than waiting.

The race is timing-dependent — the previous dispatch cleared the same sequence — so it has been latent since #27 rather than new.

💡 Solution

Two changes, each addressing one half.

Nothing is removed on a fresh tree, so do not run vcpkg to discover that. The installed set is read from installed/vcpkg/info/, which costs no process and removes this failure mode from the case that hit it. Warm trees and re-runs keep the protection #27 added.

Metrics off, so no invocation leaves a child holding the lock. This is the half that covers the two installs running back to back, which the gate does not.

🔧 Changes

File	What changed
.github/scripts/build-rocksdb-variants.sh	VCPKG_DISABLE_METRICS=1 for every invocation, and the removal step runs only when something is installed.

✅ Verification

• All three gate cases under set -euo pipefail: a warm tree names the installed .list and removes, the same tree under another triplet skips, and a nonexistent tree skips without tripping set -e.
• Full local build on arm64-osx-static taking the removal path: both variants built, public headers identical, both libraries staged.
• Archive verification on the result: markers 1 vs 0, nm 59 vs 0, probe user_key_comparison_count 40,959 vs 0.
• shellcheck clean.

The gate first used compgen -G, which review caught would never fire on a Windows-spelled VCPKG_ROOT: compgen globs the whole string and \a is an escape. find takes the directory as an operand, the way every other path in this script reaches the filesystem. Confirmed with printf-displayed paths that compgen -G matches a forward-slash path and not a backslash one.

Not verified here: the race itself, which is timing-dependent and did not reproduce locally; and the gate on Windows, where find relies on the MSYS path translation macOS does not have. If the gate ever answers wrongly the build fails loudly rather than shipping the wrong library — the staged libraries must differ, which is the check that caught the original superset bug.

_{🤖 Generated by Claude (Anthropic); posted via @cb1kenobi.}

Related PRs: #27 overlaps (added the removal step this races with; merged), #30 overlaps (merged)
Complexity: medium

_{Review-Coverage: authored=claude; ran=codex,gemini,cursor-composer,cursor-muse; adjudicated=domain; blocked=cursor-grok(failed); declined=cursor-kimi; rounds=2; full=2 @ f9e6f08}

_{Review-Attention: study ~12m (critical: build-rocksdb-variants.sh; decisions: remove-gate, metrics-opt-out-layer) @ f9e6f08}

[gemini-code-assist]

Code Review

This pull request disables vcpkg metrics telemetry to prevent lock inheritance issues and optimizes the RocksDB removal step by checking for its existence on disk before running the remove command. The reviewer pointed out that using the find command can fail on Windows runners if the native Windows find.exe takes precedence in the PATH, and suggested replacing it with a native Bash glob loop that normalizes path separators for better compatibility and performance.