mcpp run: a script artefact whose interpreter is missing fails without naming the remedy #621

Measured during the sandbox verification of the published 2026.9.12.2.

What happens

An emsdk payload installed before openxlings/xim-pkgindex#823 has no .mcpp-toolchain.json, so it names no runner (#617). mcpp run --target wasm32-emscripten then executes the JavaScript launcher directly, and the only output is:

/usr/bin/env: 'node': No such file or directory

mcpp spawned env successfully, so its own launcher diagnostics never apply, and nothing names the cause or the remedy.

Why a reinstall is not enough

mcpp refreshes its index only when a resolution misses, and emsdk@6.0.9 resolves from the old copy. Removing and reinstalling therefore installs from the old recipe again. Measured in one home:

1. Before refresh: the recipe in mcpp's index copy writes no descriptor (grep -c mcpp-toolchain.json = 0), and a remove plus reinstall produced a payload still without one.
2. After mcpp index update: the recipe in snapshot 487deaf writes one (2 matches). Remove plus reinstall produced .mcpp-toolchain.json with "runner": ".../xim-x-node/26.7.0/bin/node", and the program printed its output.

Proposal

When the run slot executes an artefact directly and the artefact's first line is a #! whose interpreter cannot be found, mcpp prints one sentence before the exec:

• it names the interpreter;
• it states that a toolchain payload names its runner in .mcpp-toolchain.json, and that one installed before its recipe wrote that file names none;
• it gives the remedy: mcpp index update, then mcpp toolchain remove <spec> and mcpp toolchain install <spec>.

The check reads the shebang and knows no toolchain, so it stays engine-generic.

The CHANGELOG entry for 2026.9.12.2 and docs/20 state the full remedy; the diagnostic is the part that would make an older payload's failure self-explaining.