fix(pypi): build uv.lock git sources with pip

[thirtyseven]

pip.parse(uv_lock = ...) passes a git-sourced package's raw uv source string (https://host/repo?rev=<ref>#<commit>) to the Bazel downloader as a URL, which cannot fetch a git repository (#4139). #4086 fixed the invalid repo name for these sources but kept the URL, so they still fail at fetch time.

This makes uv.lock git sources match how a foo @ git+... line from a requirements file is already handled:

• The src gets an empty url and filename, so _whl_repo takes the existing pip path instead of the downloader.
• The requirement line becomes a pip direct reference, foo @ git+<repo url>@<commit>, pinned to the commit uv resolved rather than the requested rev/tag/branch. Before, it was foo==<version>, which pip cannot satisfy for a VCS-only version such as 0.12.0a0+39be1c6.
• A subdirectory query parameter carries over as #subdirectory=<dir>. uv percent-encodes it (subdirectory=python%2Ffoo) and pip reads the fragment as a literal path, so it is decoded. I checked both against uv 0.9.30 and pip 26.2.1: pip fails on the encoded form with "does not appear to be a Python project" and builds the decoded one.

Tests: updated test_uv_lock_vcs_entry for the new src shape and added test_uv_lock_vcs_entry_subdirectory. //tests/pypi/parse_requirements/... and //tests/pypi/hub_builder/... pass. End to end, a large monorepo using pip.parse(uv_lock = ...) builds its git-sourced torchdata dependency against this branch via --override_module; we have been carrying the same change as a patch on 2.3.1.

Fixes #4139