Fix Python transforms on Windows (resolve interpreter from PATH candidates)

[vadimitri]

Problem

Serverless transforms fail on Windows whenever the transform is Python (src/transform.py). Subprocess hardcodes the interpreter command as python3:

INTERPRETERS = {
  'python' => { cmd: 'python3', ext: 'py' },
  ...
}.freeze

The python.org Windows installer provides python.exe and the py launcher but no python3 on PATH (only the Microsoft Store build registers a python3 alias). So Open3.popen3('python3', ...) raises Errno::ENOENT, which surfaces to the user as "interpreter not available", and there's no config to point it at python.

Fix

Make each language's interpreter a list of command candidates in priority order, and run the first one found on PATH:

'python' => { cmds: %w[python3 python], ext: 'py' },

Resolution uses a small cross-platform which that honors PATHEXT on Windows (.EXE/.BAT/…) and bare names on POSIX. Behavior is unchanged on macOS/Linux (python3 still wins); Windows now falls back to python. A genuinely missing interpreter falls back to the first candidate, so the existing "interpreter not available" error path is preserved.

No new dependencies, no config knobs — transforms just work across platforms.

Tests

• Updated the existing PATH-failure spec to the new cmds: shape.
• Added a spec proving candidate fallback: first candidate missing → next one runs.

bundle exec rspec spec/lib/trmnlp/transform_backend/subprocess_spec.rb passes (the unrelated php example needs php installed locally); rubocop clean on both files.

[trmnl-bot]

👋 Thanks for contributing, @vadimitri!

TRMNL operates a Creator Fund that pays a revenue share to OSS contributors.
We couldn't find a TRMNL account linked to @vadimitri — if you have one, add your GitHub username at https://trmnl.com/account.