fix(launcher-deps): defer dist-info prune until whole tmp_dir commits (issue #149)

[cdeust]

Summary

Fixes the Python-3.10-only flake in test_pip_install_rollback_on_mid_commit_failure (#149).

Mechanism (confirmed by deterministic forced-ordering reproducer, not just reruns):
pip_install's per-entry commit loop in scripts/launcher_deps_install.py called
_fs.prune_superseded_dist_info(deps_dir, entry) immediately after EACH individual
entry committed, inside the loop. os.listdir() order is unspecified by the Python
stdlib and differs by OS/filesystem/container image (this explains "py3.10-only in
CI, always green in 3.11-3.13" — the runners differ in directory-enumeration order,
not in pip/importlib behavior). When the *.dist-info entry happened to be
enumerated before the package-directory entry, the prune step permanently deleted
the OLD (still-valid) dist-info right after the new one committed — then the
package-directory entry's own commit failed (simulated locked .pyd on Windows;
the mid-commit-failure scenario the test exercises) and rolled back to the
ORIGINAL package files, leaving deps_dir in a genuinely inconsistent state:
package files reverted to the old version, but the old version's metadata gone.
This was a real defect in the rollback logic, not a test artifact — it just needed
the right os.listdir ordering to surface, which is why it was flaky rather than
always-failing.

Fix: collect committed *.dist-info entry names during the loop; only run the
destructive prune once the whole tmp_dir has committed successfully. The one
irreversible step now waits for confirmation of overall success regardless of
os.listdir enumeration order — closing the race by construction, not by luck of
ordering.

Also: split pip_install's commit loop into _commit_resolved_entries +
_entry_already_satisfied (this is the exact concern that carried the bug), and
extracted _remove_path to fix two pre-existing NESTING_TOO_DEEP violations in
commit_entry that the pre-commit craftsmanship hook flagged once this file was
touched. pip_install itself remains over the 50-line function budget
(pre-existing debt, mostly PEP-668-retry + subprocess-invocation logic unrelated
to #149) — documented as an out-of-scope §10 rationale rather than expanded into
this fix's blast radius.

Verification

• Deterministic forced-os.listdir-order reproducer: fails against pre-fix code,
  passes post-fix.
• New permanent regression test
  test_pip_install_rollback_preserves_dist_info_regardless_of_commit_order
  monkeypatches os.listdir to force the dangerous ordering — confirmed it FAILS
  against the pre-fix code (mutant-kill) and passes post-fix.
• 60x loop of both the original flaky test and the new regression test under
  Python 3.10.18 (provisioned locally via uv venv --python 3.10, since this
  machine doesn't have 3.10 on PATH by default): 0/120 failures.
• Full tests_py/scripts/test_launcher_deps.py: 32/32 green under 3.10.
• Full suite (uv run pytest, Python 3.13.7, this repo's normal env): 5179
  passed, 2 pre-existing failures in tests_py/hooks/test_hook_receipts.py
  (unrelated — reproduced in isolation, independent of this change; not touched
  by this diff).
• ruff check + ruff format --check: clean.

Fixes #149

🤖 Generated with Claude Code