`uv build --all-packages` deadlocks with a cold cache: wheel-lock waiters exhaust the tokio blocking pool

Finding: In an external report against uv 0.12.23 (x86_64 Linux), `uv build --all-packages` on a 54-member workspace (all hatchling plus hatch-vcs) intermittently hangs forever when the cache is cold (UV_NO_CACHE=1 or a fresh UV_CACHE_DIR); the cause is a reporter hypothesis, not confirmed [source: https://github.com/astral-sh/uv/issues/22348]. Reported observations: all 54 per-package 'Building source distribution' lines print and then output stops. The uv process has zero child processes, so no build backend is spawned. Verbose logging shows 530 'Waiting to acquire exclusive lock' messages for wheel-cache lock files within about one second, covering roughly ten shared build requirements (hatchling, hatch-vcs, setuptools-scm, packaging and others) with about 53 waiters each. The process reportedly holds about 514 threads, about 541 open lock file descriptors and 11 flocks, unchanged for over six minutes. The default five-minute lock timeout never produces an error [source: https://github.com/astral-sh/uv/issues/22348]. Hypothesized mechanism (reporter analysis, not maintainer-confirmed): contended waiters in LockedFile::lock_file use spawn_blocking with a blocking flock, and each parks one thread of the tokio blocking pool (default cap 512). The wheel-lock holder keeps its lock across download and extraction, and extraction also needs the blocking pool. When roughly 540 waiters (54 builds times about 10 shared requirements) fill the pool, holders' extraction work is queued and cannot finish, so locks are never released. The reporter also suspects the timeout around waiters does not rescue this, because a timed-out waiter still leaves its thread parked in flock [source: https://github.com/astral-sh/uv/issues/22348]. Frequency is timing-dependent: a few percent of runs on a 4-vCPU CI runner and nearly every run on a heavily loaded 4-core host. In CI the hang lasts until the job timeout [source: https://github.com/astral-sh/uv/issues/22348]. Reported workaround (not verified by KFA): build members in separate processes with bounded parallelism, sharing one cache, e.g. listing workspace paths and running `uv build` per member with xargs -P4. The reporter says this avoids the hang [source: https://github.com/astral-sh/uv/issues/22348]. Status: the issue is open, has no comments, no labels and no maintainer response in the supplied data. No fix commit or released fix is referenced. The reporter's suggestions (poll try_lock with backoff, dedupe in-process waiters with an async mutex, bound concurrent build-environment setup) are proposals only. Limitation: this is a single external report; KFA did not reproduce it, and other uv versions or platforms are unknown.