Summary

The frozen-lockfile benchmark job has been flaky, with the 10-minute step timeout firing during Benchmark 1: pacquet@HEAD (e.g. this run's log). Diagnosis:

• All 8112 tarballs reached Download completed — network side was fine (the reqwest timeouts from fix(network): set explicit timeouts on default reqwest client; enable CI tracing #267 did their job).
• Only 6997 reached Checksum verified — ~1115 stuck in the post-download stage.
• Last tracing event at 12:07:55, then 3m46s of total silence before the runner SIGKILLed the job. pacquet was still alive in the orphan-process list.

The stuck stage was this block in crates/tarball/src/lib.rs:

let cas_paths = tokio::task::spawn(async move {
    package_integrity.check(&response)...;            // SHA-512 over full tarball
    let mut archive = decompress_gzip(&response...);  // gzip inflate
    for entry in entries {                            // per-file SHA-512 + blocking write
        ...
        store_dir.write_cas_file(&buffer, ...)...;
    }
    tokio::task::spawn_blocking(...).await ...;       // SQLite INSERT
})

The body is entirely synchronous CPU + blocking I/O with no .await until the final nested spawn_blocking. Every tarball pins a tokio reactor worker for its full duration. On a 2-core GHA runner that caps concurrency at ~2 tarballs, and the tail of large packages (100-200 KB compressed, MB+ inflated, dozens of files each) overruns the 10-minute step budget. The per-second throughput trace makes it obvious:

Change

• Outer tokio::task::spawn(async move { ... }) → tokio::task::spawn_blocking(move || { ... }). The work now runs on tokio's blocking pool (default 512 threads) instead of the 2 reactor workers.
• The inner spawn_blocking around the SQLite write is no longer useful — we're already on the blocking pool — so it's inlined as a direct synchronous call.
• Comments updated, including the scope comment (the !Send tar::Archive drop-ordering reasoning no longer applies; the scope is kept for memory efficiency since the inflated buffer can be multi-MB).

What this does NOT address

CreateVirtualDirBySnapshot.run() in crates/package-manager/src/install_package_by_snapshot.rs is still called synchronously from async context, and internally uses rayon::par_iter (create_cas_files, create_symlink_layout), which also blocks a tokio worker. That's a smaller window than the tarball pipeline (dozens of files vs. the full SHA + gunzip + per-file loop), but if CI still flakes after this, that's the next thing to wrap in spawn_blocking.

Test plan

• cargo check --workspace — clean.
• cargo test -p pacquet-tarball — 7/7 pass (including packages_under_orgs_should_work, which actually downloads from npmjs.org).
• cargo test -p pacquet-package-manager — 28/28 pass (including should_install_dependencies, the end-to-end install flow).
• CI run of the Benchmark: Frozen Lockfile job — this is the real verification; the hang is timing-dependent and only triggers under the 1352-snapshot fixture's load profile.