prism run silently falls back to local Python on exit code 2, masking real container errors

[aboucaud]

What happened

When a Docker recipe exits with code 2 (argparse `SystemExit(2)` due to unrecognised CLI arguments), `prism run` silently falls back to local execution. The local Python in PATH typically lacks the project's dependencies, causing a secondary `ModuleNotFoundError` that obscures the original error from the container.

In practice: plot scripts were missing some decision CLI args. Prism passed all 6 decisions to every recipe, the scripts failed in Docker with exit code 2, Prism fell back to local Python and reported `ModuleNotFoundError: No module named 'matplotlib'` — hiding the real issue (missing argparse arguments in the plot script).

Error

Docker execution failed for 's8_constraints_figure' (exit code 2). Falling back to local execution.
Executing 's8_constraints_figure' locally (no container). Results may differ from containerised execution.
RuntimeError: Recipe for 's8_constraints_figure' failed (exit code 1):
ModuleNotFoundError: No module named 'matplotlib'

The real error (inside container) was:

error: unrecognized arguments: --ia_model nla --nonlinear_pk hmcode2020 ...

Reproduction

1. Create a recipe script that does not accept all decision CLI args (e.g. a plot script with only --universe, --n_bins, --binning_strategy)
2. Run prism run <output> --universe <name> — Prism passes all decisions, script exits with code 2
3. Prism falls back to local Python, fails with ModuleNotFoundError instead of the real argparse error

Suggested fix

• Surface the container's stderr before falling back, so the real exit code 2 error is visible
• Consider not falling back to local for exit codes that indicate script errors (2 = usage error) vs infrastructure errors (e.g. image not found)

Environment

• ASTRA: 0.1.1.dev2+gba7f65ea8
• Prism: 0.1.1
• Python: 3.14.3
• OS: Darwin 25.3.0

[aboucaud]

@EiffL can we close this now that we have verification mechanism ?