Hosted uv: after uv remove <parent> or uv lock --upgrade-package <parent> drops a hosted-pinned transitive package, its leftover override makes rollback, remove and list fail forever with hosted_wiring_contested #1445

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

Hosted scan wires a transitive PyPI package in a uv project with an override-dependencies = ["six==1.16.0"] entry plus a [tool.uv.sources] URL, and uv.lock records it under [manifest] overrides. When the user later drops the parent (uv remove isodate, or uv lock --upgrade-package isodate to a release that no longer depends on six), uv leaves both Socket lines in place, because uv never edits override-dependencies / sources for a package that just isn't resolved any more. From then on:

• rollback, remove pkg:pypi/six@1.16.0 and list all exit 1 with hosted_wiring_contested, with nothing touched.
• The remedy they print ("re-run socket-patch scan --mode hosted") succeeds (exit 0) but changes nothing, so the next rollback refuses again. The other remedy (git checkout -- pyproject.toml uv.lock) throws away the user's own uv remove / upgrade.

So a user can't unwind Socket's hosted wiring from that project at all, short of hand-editing both files. This is the uv twin of #1203 (yarn berry resolutions left behind by yarn remove / yarn up), which was fixed with the HostedInventory::stale / hosted_resolution_orphaned path. That path is only fed by yarn berry discovery.

Repro

This uses the bug-hunt mock patch API (it serves a patched six 1.16.0 wheel; it's the same harness as #1287 / #1374).

mkdir orph && cd orph
cat > pyproject.toml <<'EOF'
[project]
name = "demo"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["isodate>=0.6"]
EOF
uv lock -P isodate==0.6.1 -P six==1.16.0     # isodate 0.6.1 depends on six
uv sync
SP="socket-patch --api-url $MOCK --api-token fake --org acme --patch-server-url $MOCK"
$SP scan --yes --json        # success: override-dependencies six==1.16.0 + [tool.uv.sources] six = { url = ".../six-1.16.0-py2.py3-none-any.whl" }
uv sync --locked             # six patched

uv lock --upgrade-package isodate   # isodate 0.7.2 has no six; (or: uv remove isodate)
uv sync --locked                    # ok, six uninstalled; both Socket lines and [manifest] overrides remain
$SP rollback --yes --json           # exit 1, error.code hosted_wiring_contested
$SP remove pkg:pypi/six@1.16.0 --yes --json   # exit 1, hosted_wiring_contested
$SP list --json                     # exit 1, hosted_wiring_contested
$SP scan --mode hosted --yes --json # exit 0, success, files unchanged
$SP rollback --yes --json           # exit 1 again, hosted_wiring_contested

The refusal reads: pyproject.toml, uv.lock wire(s) Socket-hosted patches that cannot be attributed to one package version (the lockfiles disagree, or the reference is malformed), so socket-patch cannot manage them safely; reconcile the lockfiles (re-run socket-patch scan --mode hosted) or restore them from version control (git checkout -- pyproject.toml uv.lock).

Expected vs actual

• Expected: CLI_CONTRACT.md (the hosted rollback / eject section) says leftover hosted wiring that no live lock entry resolves any more, left behind because the package manager never edits it, "is not contested ... it is Socket's own leftover pin", and rollback (unscoped or scoped to its purl) and remove <uuid|purl> retire it with a hosted_resolution_orphaned warning (After yarn remove of a hosted-pinned yarn berry package, its leftover resolutions pin makes rollback, remove and list fail forever with hosted_wiring_contested, and the remedy they print (re-run the hosted scan) changes nothing #1203). The uv equivalent is an override-dependencies entry plus [tool.uv.sources] URL that the hosted run itself added (pushed_override already recognizes it) for a package that has no [[package]] in uv.lock any more. Rollback should retire both lines and the [manifest] overrides record, leaving uv.lock --locked-clean. At the very least, the printed remedy shouldn't be a no-op.
• Actual: it's classed as contested wiring. rollback, remove and list exit 1 forever, and the suggested scan --mode hosted loops.

Control (pass): a direct hosted six followed by uv remove six. uv deletes the source line itself, so nothing is left over.

Matrix (main 7236190, Linux, uv-managed Python 3.11)

Each cell ran twice: the initial command, then again after following the printed remedy. 18/18 failing cells reproduce. The wiring shape is version-independent, so I expect macOS and Windows to behave the same (I didn't probe them).

Suspect code

• crates/socket-patch-core/src/patch/redirect/upstream/mod.rs:184: HostedInventory::stale is fed only by crate::vex::discover::StaleSelector, which only vex/discover/yarn.rs:414 produces. Nothing produces a stale pin for a uv override-dependencies / sources pair whose package has left uv.lock, so HostedInventory::of (:192) puts the uuid in contested.
• crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:1617 (pushed_override) already identifies the override entry the hosted run added for a transitive package (Hosted uv rollback and remove delete a user-authored override-dependencies = ["<pkg>==<ver>"] pin that hosted mode never added #411), which is the attribution such a stale pin would need.