pip.parse: support non-sha256 --hash pins (AWS CodeArtifact serves sha512) #3972

pip.parse only recognizes --hash=sha256: pins in requirements files — index_sources.bzl splits requirement lines on that literal string, so pins using any other algorithm are silently dropped.

This matters because AWS CodeArtifact's Simple API advertises sha512 digests for hosted wheels, and lockers like uv record the strongest digest offered. A uv export lockfile for a CodeArtifact index therefore pins those wheels as:

my-package==1.2.3 \
    --hash=sha512:1266ed31df77bd2c9939b224ade65b25db25b56ccd2e9c94d4008a656dea1519d176895b9746eef3586d30e444977354440305eb900ac84e2394b1acecfe9935

With experimental_index_url, pip.parse treats the entry as hash-less and falls back to trusting whatever the index lists:

DEBUG: /home/runner/.cache/bazel/_bazel_runner/.../external/rules_python+/python/private/repo_utils.bzl:101:16:
rules_python:my_module:pypi:hub:my_pip WARNING: requirement file has been generated without hashes, will use all hashes for the given version 1.2.3 that could find on the index:
    ["b0fd6065e31278409509c593276c4fe66948ad6a16800c7dec93f9b7d92ac267"]

The lockfile's pin is ignored, so the artifact is no longer verified against what was locked.

Feature request: parse --hash=<algo>:<digest> for the other PEP 503/691 algorithms (at least sha512) and match them against the index metadata, which already carries multi-algorithm digests in the PEP 691 hashes dict.

Observed on rules_python 2.0.3; the parsing is unchanged on main.

Current workaround: post-process the exported lockfile, replacing each sha512 pin with the wheel's sha256 computed from the downloaded bytes.