Evict corrupt cached Python archives - #191

[P2] Coordinate eviction with shared-cache writers

On Unix, installs with different installation directories can share UV_PYTHON_CACHE_DIR; the callers' installation-directory locks do not serialize them. Two readers can open the corrupt archive, one can remove it, and a subsequent attempt can publish a valid replacement before the slower reader reaches this removal. That reader then deletes the replacement, potentially causing the downloader's subsequent File::open to fail with NotFound. Use a cache-entry lock covering opening, publication, validation, and eviction so removal targets the archive that failed verification.

[P2] Preserve the hash mismatch when eviction fails

If the cached archive is readable but cannot be deleted, such as in a read-only shared cache, this return replaces the confirmed HashMismatch with the cleanup I/O error. Callers consequently lose the integrity-failure diagnostic and its expected/computed hashes. Keep eviction best-effort and report its failure separately while returning the original mismatch, or retain both errors in a contextual error.

[P3] Exercise a cache hit in the entry-lock test

This fixture creates the cache directory and lock, but never writes ababababa-python.zip. It therefore exercises a cache miss: a refactor that locks only downloads while leaving cached readers unlocked would still pass, despite breaking eviction coordination. Seed the matching cached archive before acquiring the lock so this test verifies that existing-archive reads wait too.

[P3] Make the archive fixture's contents explicit

These bytes encode a valid ZIP containing an empty python/python file. Successful extraction is essential here: malformed archive data would return ExtractError before reaching hash validation. The opaque byte array hides that requirement and makes fixture changes require understanding ZIP encoding. Prefer constructing named archive entries with the existing uv_test::archive::write_tar_gz helper in the python_install.rs integration module, and document why the expected digest deliberately differs.

[P3] Separate the read-only cache scenario into a named test

This Unix-only block checks retention when lock acquisition fails, while the invocation below checks eviction after successful locking. These are independent regression scenarios: a failure here prevents the eviction assertion from running on Unix, and the read-only behavior cannot be selected independently. Following the repository’s test guidance, move this scenario into a separate #[cfg(unix)] test with explicit fixture setup, leaving the writable-cache eviction test cross-platform.