[FR]: A first-party wheel rule that builds with uv's backend

### What is the current behavior?

py_wheel is re-exported verbatim from rules_python (py/defs.bzl:49), and takes the distribution's identity and metadata as rule attributes: distribution, version, requires, entry_points, classifiers, summary, license, project_urls, python_requires.

All of those facts are already in pyproject.toml, which the uv extension reads to resolve dependencies. A uv project that also publishes therefore states its metadata twice and has to keep the copies in sync. That is a super big footgun if you build a few wheels.

The user experience is also questionable with the current rules_python py_wheel implementation. I don't quite understand why we need a build backend reimplemented in bazel that is not even PEP compliant.

### Describe the feature

A uv_wheel rule that builds a first-party wheel by running uv build so nothing about the distribution is repeated in the BUILD file:

```
uv_wheel(
name = "wheel",
srcs = ["greeting/banner.txt"], # package data
deps = [":greeting"],
)
```

uv build's backend (build-backend = "uv_build") is compiled into the uv binary, so a pure-Python wheel needs no build dependencies, no Python interpreter and no network:

```
uv build --wheel --no-config --offline --no-cache \
--no-build-isolation --no-python-downloads \
--project --out-dir
```

This would make the whole bazel python work a lot more pythonic and user friendly.

Start at py/defs.bzl:49, where py_wheel is re-exported from rules_python, and review the existing py_wheel interface. Then examine the proposed uv_wheel inputs and the documented uv build command, including staging srcs and producing a wheel offline. Done means a first-party wheel can be built from project metadata without repeating distribution attributes in BUILD files.

Written by the indexing model from the issue text.