…sh#7500)

## Summary

See: astral-sh#7485. The test was using `uv
pip sync` which doesn't require fetching metadata, and the failure was
in fetching metadata.

This changes the structure of the hints generator in the resolver when
encountering solution errors, so that it re-uses a single output buffer
owned by the caller.
It avoids repeated allocations of a temporary buffer within each
recursive function call.

…stral-sh#7470)

Closes astral-sh#7469

…sage (astral-sh#7502)

Closes astral-sh#7489

## Summary

This adds about 50 KB to the binary:

```
❯ du ./target/release/socks
44736	./target/release/socks

❯ du ./target/release/uv
44632	./target/release/uv
```

So need some input on whether it's worth supporting.

Closes astral-sh#7484.

More whack-a-mole following in the tradition of astral-sh#7012.

Recently, rkyv 0.8 was released. Its API is a fair bit simpler now for
higher level uses (like for us in `uv`) and results in us being able to
delete a fair bit of code. This also removes our last dependency on `syn
1.0`, and thus drops that dependency.

Performance (via testing on the `transformers` example) seems to remain
about the same, which is what was expected:

```
$ hyperfine -w5 -r100 'uv lock' 'uv-ag-rkyv-update lock'
Benchmark 1: uv lock
  Time (mean ± σ):      55.6 ms ±   6.4 ms    [User: 30.4 ms, System: 35.1 ms]
  Range (min … max):    43.0 ms …  73.1 ms    100 runs

Benchmark 2: uv-ag-rkyv-update lock
  Time (mean ± σ):      56.5 ms ±   7.2 ms    [User: 30.5 ms, System: 36.3 ms]
  Range (min … max):    39.1 ms …  71.5 ms    100 runs

Summary
  uv lock ran
    1.02 ± 0.18 times faster than uv-ag-rkyv-update lock
```

Closes astral-sh#7415

## Summary

Closes astral-sh#7493.

…7523)

This stands out alongside other messaging which uses the longer spelling
"virtual environment"

As mentioned in astral-sh#7509

As we support more complex Python discovery behaviors such as:

- astral-sh#7431 
- astral-sh#7335 
- astral-sh#7300 

`Any` is no longer accurate, we actually are looking for a reasonable
default Python version to use which may exclude the first one we find.
Separately, we need the idea of `Any` to improve behavior when listing
versions (e.g., astral-sh#7286) where we do actually want to match _any_ Python
version. As a first step, we'll rename `Any` to `Default`. Then, we'll
introduce a new `Any` that actually behaves as we'd expect.

…-sh#7530)

I think it's best practice to use a placeholder when we transform
something, and astral-sh#7522 is having snapshot issues because this filter
conflicts with `with_filtered_virtualenv_bin`

…7526)

As in astral-sh#7514

…al-sh#7517)

Follow-up to astral-sh#7514 and astral-sh#7526 adding
the `Any` variants again with slightly different semantics (i.e., they
allow pre-releases)

We'll be able to use this in astral-sh#7508
to avoid querying a bunch of alternative interpreters unnecessarily in
the non-list case.

…al environment (astral-sh#7522)

Closes astral-sh#7519

When sending an upload request, we use HTTP formdata requests, which can't be cloned (seanmonstar/reqwest#2416, plus a limitation that formdata bodies are always internally streaming), but also know that we need to always have credentials.

The authentication middleware by default tries to clone the request and send an authenticated request first. By introducing an `only_authenticated` setting, we can skip this behaviour for publishing.

Split out from astral-sh#7475