Fix Python variant tagging in the Windows registry (#19012)
## Summary
This adds a regression test and fix for #18795. I ran the test and
confirmed reproduction before implementing the fix.
The underlying bug here happens only on Windows, and only when
exercising the PEP 514 Python installation registration pathway (which
the integration tests disable by default, since it involves global
mutable state that leaks between tests). The bug itself is just an
imprecision in how we compute the "tag" for the Python entry -- we
weren't including the variant (the `t` in `3.14t`), so two distinct
installs (`3.14` and `3.14t`) would end up with the same registry tag.
For an end user, this surfaces as Python installation entries missing
when running `uv python list`.
One thing to note about the test here is that it _does_ exercise the
Windows registry pathway, which means that it intentionally bypasses the
guardrail around global mutations in the integration tests. This is
"fine" in the sense that there are on other tests observing that state
at the moment, but I think it's a risk in terms of isolation (in the
sense that devs who run our integration tests will actually observe
global changes to their Python installations, plus any failure in the
test means we won't clean up our global changes). Two options there:
- I could try and harden/isolate the registry mutation pathways a bit
more, e.g. we could add `UV_DEV_WINDOWS_REGISTRY_COMPANY_KEY` or
something like that to do some more test-level isolation of HKCU writes.
This still modifies global state, but at least it'll be more namespaced.
- I could remove the integration test entirely, now that we've confirmed
that the fix itself works. This leaves us without coverage, but given
that the fix itself is ~2 lines that might be acceptable.
Fixes #18795.
## Test Plan
This PR includes a regression test.
---------
Signed-off-by: William Woodruff <william@astral.sh>
