feat: remove input-hash for PyPI dependencies

[nichmor]

Replace hash-based validation for path-based PyPI packages with metadata-based validation. Instead of computing and storing a hash of pyproject.toml, setup.py, and setup.cfg, we now:

1. Don't store any hash in the lock file for path-based packages
2. During satisfiability checks, parse pyproject.toml and compare the name and version with the locked metadata

This approach is similar to how PR #5011 removed input_hash for conda packages. The metadata comparison is more explicit about what changed (name vs version) rather than just indicating "something changed via hash mismatch".

Changes:

• pypi.rs: Stop computing and storing hash for SourceDist::Path and SourceDist::Directory
• satisfiability/mod.rs: Replace PypiSourceTreeHashable hash comparison with metadata parsing and comparison
• Add PypiSourceMetadataMismatch and PypiSourceMetadataError types
• Remove SourceTreeHashMismatch type and related imports

Description

Fixes #{issue}

How Has This Been Tested?

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: {e.g., Claude, Codex, GitHub Copilot, ChatGPT, etc.}

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added sufficient tests to cover my changes.
• I have verified that changes that would impact the JSON schema have been made in schema/model.py.

[baszalmstra]

Nice! This is a good start but its not enough, we need to also compare the requirements, required python version optional dependencies, etc. Furthermore, some fields can be dynamic which means we need to invoke python, and we might also have to deal with setup.py only sources.

[tdejager]

Nice! This is a good start but its not enough, we need to also compare the requirements, required python version optional dependencies, etc. Furthermore, some fields can be dynamic which means we need to invoke python, and we might also have to deal with setup.py only sources.

Indeed! It might be good to let Claude explore the uv codebase as well for inspiration, although if I recall their satisfiability check is less extensive, they regenerate more often.