feat: add uv toolchain extension

[jbedard]

Add a UV module extension/toolchain for fetching UV via bazel.

Changes are visible to end-users: yes

• Searched for relevant documentation and updated as needed: yes
• Breaking change (forces users to change their own code or config): no
• Suggested release notes appear below: yes

The uv module extension's new toolchain() tag downloads a hermetic uv and publishes @uv (host alias) plus @uv//:all (per-platform toolchains).

Test plan

• Covered by existing test cases
• New test cases added
• Manual testing; bazel run @uv -- --help

[aspect-workflows]

Bazel 8 (Test)

All tests were cache hits

121 tests (100.0%) were fully cached saving 58s.

---

Bazel 9 (Test)

All tests were cache hits

120 tests (100.0%) were fully cached saving 1m 2s.

---

Bazel 8 (Test)

e2e

All tests were cache hits

55 tests (100.0%) were fully cached saving 51s.

---

Bazel 9 (Test)

e2e

All tests were cache hits

55 tests (100.0%) were fully cached saving 1m.

---

Bazel 8 (Test)

examples/uv_pip_compile

All tests were cache hits

1 test (100.0%) was fully cached saving 444ms.

---

Buildifier

[dzbarsky]

This extension feels bloated. Would be better to split tool and package bits into separate ones, that's how other languages work. You can still name it uv, just put it in separate bzl file. As a bonus it will lead to fewer transitive bzl invalidations.

The other concern I have - is the extension still reproducible given the host -specific bits?

[jbedard]

I've moved this to a new file and new module_extension to better separate the uv tool vs uv-lockfile-consumption, which I think is a good separation?

For the rctx.os-specific alias() within a reproducible=True extension... that seems to be a bit of a grey area, but I think bazel should handle this correctly because the uv_hub_repository() repo rule creating this alias() sets configure = True. IMO we should keep the reproducible=True under the assumption that bazel understands the use of rctx.os.*+configure=True...