Add pypa/packaging conformance tests for PEP 440 specifier parsing

[Stella Huang (StellaHuang95)]

What

Adds a data-driven conformance suite that validates PythonVersionSpecifier /
PythonVersion against pypa/packaging, the reference PEP 440 implementation.

requires-python in a PEP 723 inline-script block is a PEP 440 version specifier, and
we evaluate it ourselves (in matchesPythonVersion) to choose a base interpreter and to
decide which Python version to ask uv to install. This pins that behaviour to the
reference implementation so edge cases can't drift.

118 cases ported from tests/test_specifiers.py:

Suite	Cases	Asserts
rejects specifiers packaging rejects	31	tryParse returns undefined
matches packaging semantics	85	matches() equals packaging's result
diverges from packaging by design	2	our intentional behaviour

How expected values were produced

They were generated by calling packaging 24.1 directly, not hand-transcribed.

Two things to know when re-generating:

1. Prerelease semantics. Upstream's harness constructs Specifier(spec, prereleases=True),
   which is not packaging's default. Expected values here use the default, which is the
   correct model for requires-python. Against the default we match packaging on all 85 cases.
2. Scope. Cases using epochs (2!1.0), local labels (2.0+deadbeef), post/dev releases,
   or more than three release segments are omitted. A Python interpreter version never has
   them, and PythonVersion deliberately does not model them (see its class doc).

The two intentional divergences

packaging's Specifier.prereleases auto-enables prereleases only for ==, >=, <=, ~=
and === — < and > are excluded. So under packaging's default:

• >3.0.0a7 matches only final releases (3.0.0, 3.0.1); it rejects 3.0.0a8, 3.0.0b1, 3.0.0rc1
• <3.0.0a8 rejects every 3.x prerelease

Our rule is uniform: any clause naming a prerelease enables prereleases. That is what the
class docs describe and what pythonVersionSpecifier.unit.test.ts already asserts for
<3.14.0rc2. These two cases are isolated in their own suite with the reason recorded, so
they're an explicit decision rather than an accidental mismatch.

Testing

• 118/118 new tests pass
• npm run lint clean on the new file
• Full unit suite: 2220 passing, 0 failing

Licensing

pypa/packaging is dual-licensed Apache-2.0 / BSD-2-Clause. The ported test data is used
under BSD-2-Clause, with source, copyright and licence recorded in the file header.
No production code is affected — this PR adds a test file only.