Use sys.executable instead of "python" in subprocess tests

[kmatzen]

Fixes #86. Re-lands the content of #93 against main.

#93 was merged into cleanup-structure, which was subsequently bypassed when the rest of the work was rebased onto main. The fix never reached main as a result, so this is the same change applied directly.

The problem

62 tests spawn a subprocess with the literal executable name python, which does not exist on modern macOS or on many Linux distributions where only python3 is installed.

CI does not catch it: uv sync provides a venv in which python resolves. The breakage is invisible in CI and hits anyone running pytest directly.

Effect

On main, locally: 61 failed / 592 passed → 653 passed, 0 failed.

File	Was failing
tests/test_manifest_not_exists_coverage.py	39
tests/test_ls_command_coverage.py	13
tests/test_git_root_coverage.py	9

sys.executable is correct regardless of environment and additionally guarantees the subprocess runs under the same interpreter as the test, rather than whichever python happens to be first on PATH.

Notes

• tests/test_s3lfs.py's method="python" is deliberately untouched — that names a compression backend, not an interpreter.
• Some lines needed rewrapping, since sys.executable is longer than "python" and pushed them past black's 88-char limit. That is the whole of the non-mechanical diff.
• The CI-trigger widening that accompanied Use sys.executable instead of "python" in subprocess tests #93 is already on main, so it is not repeated here.

Why it matters beyond convenience

A suite with 61 permanent failures cannot be used as a local signal. During this work I misread a baseline for exactly that reason — comparing against a tree built with git archive (which omits .git) and wrongly concluding a change had fixed 28 tests. Constant background noise makes that class of error easy to make and hard to notice.

🤖 Generated with Claude Code

https://claude.ai/code/session_019UrDtdFKGwQZp8oYGwL2rj