Flaky: archive_cache::preparation_safety_survives_fallback_and_cache_hit fails ~50% under parallel -p perry --bins #9083

commands::compile::link::archive_cache::tests::preparation_safety_survives_fallback_and_cache_hit fails roughly half the time under the full parallel cargo test -p perry --bins run, and always passes in isolation. It is not attributable to any branch — I hit it while auditing #9070 and alternated main/PR twice to check:

2 of 4 on each side, and isolated it is green:

$ RUST_TEST_THREADS=1 cargo test -p perry --bins -- --exact \
    commands::compile::link::archive_cache::tests::preparation_safety_survives_fallback_and_cache_hit
test result: ok. 1 passed; 0 failed; 1065 filtered out

The failure is the test's own precondition, not a behavioural assertion:

panicked at crates/perry/src/commands/compile/link/archive_cache.rs:438:13:
a valid cache hit must not prepare the archives again

That is the tell described in CLAUDE.md's perry-runtime note — a fixture precondition failing means another thread perturbed shared state, not that the code under test regressed. The difference is that this is perry, not perry-runtime, so it is not covered by the RUST_TEST_THREADS=1 pin that every CI path applies to the runtime crate; -p perry --bins runs on the default pool.

Two candidate mechanisms, not yet separated:

• the archive-cache tests share on-disk state under the target dir (a sibling test preparing or invalidating archives concurrently would make "a valid cache hit" stop being valid), or
• mtime granularity — a cache-validity check that compares timestamps can tie when two operations land in the same filesystem tick, which would explain why a faster run is likelier to fail.

Worth noting this is the same crate as the perry bin tests that mutate global PATH, so a per-test-isolated fixture directory (rather than a shared one) is the likely fix. Until then it is a real source of false reds on any PR that happens to touch this crate — I nearly attributed it to #9070.