Fix vendored PyPI revert of entries wired across flavors (#1524)

[Mikola Lysenko (mikolalysenko)]

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

Fixes #1524

What it does

Vendored PyPI entries whose wiring spans two backends can now be
reverted. The #1524 case: a project vendors requirements.txt, then a
pylock.toml appears and the next scan --mode vendored wires it too.
Before this fix, vendor --revert exited 0 with success and restored
nothing, remove exited 1, and the hosted takeover refused. Each printed
a remedy that couldn't be followed. Now the revert restores both files
and deletes the wheel.

Root cause

A re-run restamps the entry's flavor (requirements → python-lock),
but carry_forward_wiring keeps the earlier requirements_line
records. That is deliberate, because the revert still has to restore
that file. revert_pypi_opts then sent the whole entry to the backend
of that one flavor, and each lock backend calls a record it doesn't own
drift (vendor_lock_entry_drifted: unexpected Python wiring file or kind: requirements.txt (requirements_line)). So the CLI's own wiring
kept the entry, and the wheel, forever. Any mix fails the same way:
requirements then poetry/pdm, or a pylock record under a requirements
entry, which the requirements revert read as a vendor line in
pylock.toml.

Fix

• Revert by record kind. revert_by_record_kind (vendor/pypi.rs)
  replaces the uv/Pipenv-only revert_with_sibling. It sends each
  record to the backend that owns its kind (record_owner), in this
  order: requirements lines, then pylock records, then other backends'
  records, then the entry's own flavor. If a later group fails or is
  drift-kept, the earlier groups' files are put back, the same rollback
  the uv and Pipenv export paths already had. A kind no backend owns
  stays with the entry's flavor, so its backend reports it as before.
  When one backend owns every record, that backend reverts the entry,
  even if it isn't the flavor the entry is stamped with (Bugbot finding,
  00abb90).

• Takeover preflight by record kind (faf549a, review finding). Now
  that a mixed entry reverts fully, preflight_pypi_takeover checks
  reach the same way:

  • requirements_line records under any non-requirements flavor;
  • the uv check whenever the entry holds uv_ records;
  • the Poetry check whenever it holds poetry_ records.

  Without this, a poetry/pdm/pylock entry could have a requirements line
  in a -r include, or an appended transitive line, reverted with no
  hosted pin to replace it.

• Routing note. The pypi_multiple_lockfiles note used to say an
  already vendored requirements.txt "retain[s] its existing sources".
  When requirements.txt holds this package's # socket-patch vendor:
  line, the note now says it "keeps its vendored wiring". The check uses
  the requirements backend's own vendor-line parser.

The npm, PyPI and gem wrappers only dispatch to the binary and have no
revert logic, so they need no change.

Tests (red before the fix, green here)

Issue / case	Regression test	Before the fix
#1524: requirements then pylock.toml (revert, dry-run, routing note)	vendor::pypi::tests::requirements_then_pylock_entry_reverts_both_files	main: vendor_lock_entry_drifted: unexpected Python wiring file or kind: requirements.txt (requirements_line)
#1524 variant: requirements then poetry.lock / pdm.lock	vendor::pypi::tests::requirements_then_tool_lock_entry_reverts_both_files	main: ignoring wiring record for unexpected file requirements.txt (only poetry.lock is poetry-owned), artifact kept
#1524 variant: requirements entry carrying a pylock record	vendor::pypi::tests::requirements_entry_with_a_pylock_record_reverts_both_files	main: pylock.toml: the vendor line ... changed since vendoring + residual reference
#1524 variant: all records owned by a backend other than the stamped flavor	vendor::pypi::tests::entry_whose_records_all_belong_to_another_flavor_reverts	4bc92fa and main: drift-kept by the stamped flavor's backend
takeover of a mixed entry with an include or transitive requirements line	patch::redirect::pypi_takeover::tests::requirements_lines_under_another_lock_flavor_are_checked, uv_records_under_another_flavor_are_checked	00abb90: preflight admitted it

Local runs:

• cargo fmt --all -- --check: clean (faf549a).
• cargo clippy --workspace --all-features -- -D warnings: clean (faf549a).
• cargo test -p socket-patch-core --lib --all-features (4bc92fa): 6478
  passed, 4 failed. The 4 are chmod-based tests (copy_tree symlinked
  root, vlt_heal unremovable lock, poetry/requirements write failure).
  They fail because this sandbox runs as uid 0, which ignores permission
  bits; Fix hosted/vendored cargo floor reads (#653, #651) #1429 reports the same 4 on main. On faf549a,
  patch::redirect::{pypi_takeover,requirements} passed 32/32.
• cargo test -p socket-patch-cli --all-features --test mode_migration_pypi -- --include-ignored
  (faf549a): 63 passed.
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_pypi_build -- --include-ignored
  (uv 0.11.32, 4bc92fa): 55 passed.
• CI on faf549a: every check green (ci-ok success). Bugbot found no new
  issues.

/code-review high raised 9 findings on the first version. This version
addresses them:

• per-kind dispatch instead of a single-pair special case;
• the routing note uses the vendor-tag parser, which handles sdists,
  dotted names, comment lines and other packages' lines, and reads files
  with read_regular_to_string;
• the note no longer claims a lock reverts with it;
• tests for the other flavor mixes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GtbdfcgfARj65ipZ22JEDm

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[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 faf549a. Configure here.}