pip_compile test: configurable retry for uv on transient network failures?

When the generated `_test` target hits a transient network error, the whole run is
lost and the next attempt starts from nothing:

```
Connection refused (os error 111)
Failed to extract archive ... I/O operation failed during extraction
```

That is expensive with a lot of dependencies. `--no-cache` is hardcoded in
`uv/private/pip_compile_test.sh`, so every retry re-downloads everything — and with
`--generate-hashes`, direct-URL pins are downloaded in full to be hashed, several GB per
run for us. Retrying at the Bazel level with `--flaky_test_attempts` pays that full cost
again and still records the failed attempt. `UV_HTTP_RETRIES` doesn't cover all of it —
`Failed to extract archive` isn't retried — and its backoff roughly triples per step, so
raising it pushes us into the test timeout instead.

Would it be possible to add a configurable retry inside the test — say 3 attempts by
default — together with a scratch `--cache-dir` created and removed per run instead of
`--no-cache`? The directory would start empty every run, so resolution stays exactly as
fresh, but it would survive between attempts, so a retry only re-fetches what the failed
one missed.

Start with uv/private/pip_compile_test.sh and trace how the generated _test target invokes uv and handles attempts. Compare the current --no-cache behavior with the requested per-run scratch cache and define done as configurable in-test retries that reuse that cache without changing fresh-run resolution.

Written by the indexing model from the issue text.