What this fixes

CI runs of Integrated-Benchmark frequently hang at:

Compiling pacquet-cli v0.0.1 ...
    Finished `release` profile [optimized] target(s) in 2m 50s
Benchmark 1: pacquet@HEAD
Error: The action 'Benchmark: Frozen Lockfile' has timed out after 10 minutes.

With --show-output already enabled, the absence of any pacquet stderr after Benchmark 1: means the install process genuinely went silent — no progress, no error, no panic. That rules out "bench is slow" and points at something blocking inside pacquet with no deadline on it.

Root cause

crates/network/src/lib.rs:31 hands back Client::new(), which has no connect/request/pool-idle timeouts. The sibling from_client docstring even called this out as a footgun:

Primarily useful for tests that need custom timeouts (a default Client has no connect / request timeout, so a firewall that silently drops packets instead of refusing them can stall the test suite for TCP-retry worth of time).

Every http_client.get(tarball_url).send() in crates/tarball/src/lib.rs:310 is therefore a potential forever-hang. The bench's verdaccio is a single Node process handling 16 concurrent requests from pacquet; on a GHA runner it's easy for the event loop to stall (GC, uplink hiccup, TCP packet loss without RST) for longer than our patience. Pacquet then sits on the half-open socket until the GHA job timeout, which is exactly the symptom.

Pacquet has no retry on transient network failures yet (tracked separately in #259), so even a transient stall becomes a permanent hang in the current code.

Changes

1. ThrottledClient::new_from_cpu_count now builds its Client with explicit defaults:
   • connect_timeout(10s) — generous for localhost, snaps on resource-exhausted runners.
   • timeout(60s) — per-request deadline. Typical npm tarball < 5 MB, so 60s on localhost has huge margin; a real hang turns into TarballError::FetchTarball and hyperfine reports the non-zero exit instead of silent-hang-until-timeout.
   • pool_idle_timeout(30s) — evicts connections that verdaccio closed but we didn't notice.
2. from_client docstring updated — it's still the escape hatch for tests that want different (usually shorter) timeouts, not "the only way to get any timeouts at all".
3. CI bench step now runs with TRACE=pacquet=info. pacquet's tracing subscriber is gated on the TRACE env var; without it, --show-output only ever captured an empty stream. With it, the next stall will show which phase the stuck install was in ("Download completed", "New cache", "Reusing cached CAFS entry") before going silent.

What this doesn't fix

This converts hangs into fast failures rather than preventing the stall itself. If verdaccio genuinely starts dropping requests, pacquet will now surface that as a FetchTarball error → hyperfine exits non-zero → the step fails visibly, but the underlying resource-exhaustion or verdaccio-instability problem still needs addressing. Options once we have the first post-fix log:

• Add retry-with-backoff on transient network errors (Tarball fetch has no retry on transient network errors #259).
• Investigate why verdaccio stalls under 16-permit load on the GHA runner specifically.
• Reduce concurrency (cap on pacquet's request semaphore or ThrottledClient permit count).

Test plan

• cargo check --workspace --all-targets.
• cargo test -p pacquet-network -p pacquet-tarball -p pacquet-package-manager — no test regressions (tests that use fast_fail_client with sub-second timeouts still work; they set their own Client::builder).
• Next CI Integrated-Benchmark run — expected outcome: either the bench runs green (hang was network-stall-related and 60s timeout now catches it), or it fails with TarballError::FetchTarball plus a tracing trail showing the last phase before the stall. Either way, actionable rather than silent.