Fix uv/Hatch hosted re-pin to a newer patch (#742, #650)

[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Refs #742
Refs #650

Summary

Hosted scan now moves a uv project, a uv PEP 723 script lock or a Hatch
project to a superseding patch for a package it already wired. Before
this, the run listed the upgrade in updates[] and then refused its own
earlier pin as a user source. It exited 0 with
redirect_uv_project_unsupported, redirect_uv_script_unsupported or
redirect_hatch_unsupported, and the project kept installing the old
patch. If that artifact was ever withdrawn, every fresh install would 404.

Root cause

Both pyproject source writers decide whether an existing pin may be
replaced:

• uv: same_hosted_artifact in utils/python_script.rs accepted only a
  rotated grant token on an identical path, and a test pinned a
  different patch uuid as a refusal.
• Hatch: replacement in utils/hatch.rs accepted only a
  byte-identical URL.

Neither recognized socket-patch's own hosted reference under an older
patch uuid. Pipenv already handles this correctly through the shared
hosted_pypi_reference recognizer.

Fix

New replaceable_hosted_pin(previous, current, name, version) in
vendor/lock_inventory/pypi.rs. It is built on the shared hosted PyPI
recognizer: the pin must be on patch.socket.dev or the configured
--patch-server-url origin (path prefix allowed), with no userinfo, and
its /patch/pypi/<name>/<version>/<grant>/<uuid>/<artifact> coordinates
must match the package and version. The uv writer, the Hatch writer and
Pipenv's owned_url all use it, so every PyPI hosted lane shares one
definition of "our own pin". Pins on another host, with credentials, for
another release, or vendored path sources are still refused.

Scope / remaining slice

This PR covers hosted mode only. Vendored re-vendoring to a newer uuid
(pypi_uv_source_already_exists, pypi_lock_source_already_exists,
pypi_hatch_unsupported) needs a revert-then-rewire path in the vendored
PyPI backends. The requirements.txt vendored lane has the same gap. That
is why both issues are Refs, not Fixes, and stay open for the
vendored follow-up.

Tests (red → green)

Issue	Test	Before fix	After
#742 project	tests/hosted_superseding_pypi.rs::uv_project_repins_superseding_patch (two real CLI hosted scans vs. a mock API switching uuid A→B)	FAIL redirect_uv_project_unsupported	pass
#742 script	::uv_script_lock_repins_superseding_patch	FAIL redirect_uv_script_unsupported	pass
#650 pyproject	::hatch_pyproject_repins_superseding_patch	FAIL redirect_hatch_unsupported	pass
#650 hatch.toml	::hatch_toml_repins_superseding_patch	FAIL redirect_hatch_unsupported	pass
#742	patch::redirect::superseding_repin_tests::{uv_project,uv_script_lock}_repins_to_a_superseding_patch (LF + CRLF; uv.lock hash replaced)	FAIL	pass
#650	patch::redirect::superseding_repin_tests::hatch_project_repins_to_a_superseding_patch	FAIL	pass
#742	utils::python_script::tests::superseding_patch_repins_own_hosted_source (project + script, custom path-prefixed origin, foreign host/version/userinfo still refused)	FAIL	pass
#650	utils::hatch::tests::superseding_patch_repins_own_hosted_reference	FAIL	pass

Local checks:

• cargo clippy --workspace --all-features -- -D warnings: clean.
• New and changed code is rustfmt-clean. main itself is not
  rustfmt-clean, and CI has no fmt gate.
• cargo test --workspace --all-features: 9733 passed, 12 failed. All 12
  failures are permission-denial tests (chmod 0o555 / read-only files)
  that cannot fail when run as root, which this sandbox is. None touch
  this change, and CI runs them as non-root.
• CI on d0d9102: every check passed (3 skipped by path filters). Bugbot:
  no issues.

Docs: CHANGELOG [Unreleased] / Fixed entry; docs/testing/hatch.md
notes the hosted re-pin.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit d0d9102. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at d0d910218a.

• CI: 475/475 latest check runs green on the head (skipped/neutral excluded: 3 skipped, 1 cancelled Bugbot re-request); mergeable, no conflicts.
• Bugbot: reviewed d0d9102 — no issues found; no unresolved review threads.
• Reviewer note: vendored re-vendor to a newer patch is a separate follow-up slice (per the status block).

---

Generated by Claude Code