feat(exec): run python inside containers

[jahvon]

Part 3/5. Stacked on #440.

Summary

Combines interpreter: python with the existing container: block, so a pinned Python toolchain needs no local install.

exec:
  interpreter: python
  cmd: |
    import sys
    print(sys.version)
  container:
    image: python:3.13-alpine

Notable Changes

• Inline code is bind-mounted read-only as a script and passed via spec.Script, never spec.Cmd. buildRunArgs maps Cmd to <entrypoint> -c <code>, which would put user code in the process table and cost traceback line numbers — the same trade-off Part 1 avoided on the host. The existing "script lives outside every mount" branch already did exactly this for files, so the generated temp script reuses it and internal/services/run/container.go needed no change at all.
• The default entrypoint follows the interpreter — sh for a shell command, python3 for a Python one. Resolved in the runner rather than on ExecContainer, keeping the types package unaware of how flow launches containers. An explicit container.entrypoint still wins, including the empty form (which, with Python, only works if the image's own ENTRYPOINT is an interpreter — documented).
• Host interpreter discovery stops at the container boundary. VIRTUAL_ENV, PYTHONPATH, PYTHONHOME, and FLOW_PYTHON_BIN are dropped from the container environment: those host paths either do not exist inside it or, worse, resolve to an unrelated mounted directory. PYTHONUNBUFFERED is set there too.
• The temp script cleanup is registered as a context callback next to ForceRemoveContainer, so a run abandoned by the runner's timeout goroutine does not leak it.

Testing

• Unit tests assert the built spec: Cmd empty, Script set to a .py, the script mount present and read-only, the python3 entrypoint default, explicit-entrypoint override, empty-entrypoint passthrough, that a shell command still gets sh, and that host python env vars are dropped while unrelated ones survive.
• An e2e case runs Python in a python:3.13-alpine image, behind the suite's existing runtime guard.
• flow validate passes; generate produces no diff.

Verification note: I have no container runtime on this machine, so the live container run was not executed locally — it is covered by the e2e case, which only executes where a runtime is available (CI). The spec and argv construction are verified by the unit tests above.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R328pa3FUUfga4gYah1iQi

[codecov]

Codecov Report

❌ Patch coverage is 91.17647% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/runner/exec/container.go	89.65%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!