chore: migrate uv to upstream main exposing resolver construction API

[wolfv]

Description

uv 0.11.16 privatized several APIs that pixi's PyPI resolver depends on, with no public replacement:

• the custom-resolver-provider construction path — Resolver::new_custom_io, DefaultResolverProvider::new, AllowedYanks::from_manifest, PythonRequirement::from_marker_environment — that lets pixi inject its conda-aware CondaResolverProvider
• the client-sharing hooks — uv_client::ExtraMiddleware, BaseClientBuilder::custom_client
• RegistryWheelIndex::get / IndexEntry

These have now been restored as pub upstream (a visibility-only change). That change landed on astral-sh/uv main after the 0.11.26 release, so this PR points the uv-* dependencies at a pinned main rev of uv for reproducibility, and updates pixi's call sites for the rest of the 0.11.x API surface. Client/middleware sharing is preserved end-to-end (mirrors, custom auth, shared TLS client) — no behavior is stubbed out.

Follow-up: once uv publishes a release that includes these pub items (0.11.27+), switch the deps from the pinned rev to that tagged version.

How Has This Been Tested?

• cargo check --workspace — clean
• cargo fmt --all — clean; cargo clippy --workspace --all-targets -- -D warnings — no warnings
• Unit tests: pixi_uv_conversions (29), pixi_install_pypi (45), pixi_uv_context (3) — all passing
• Full integration matrix (linux/macos/windows) via the test:extra_slow label

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.

Tools: Claude Code

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly the pinned-uv rationale in Cargo.toml
• I have added sufficient tests to cover my changes.