Batch mode: exit 1 when a script command failed (#117)

[vv137]

Fixes #117.

The bug

molterm --script f.mt --no-tui returned 0 even when commands in the script
failed.

The diagnostics were all there — per-failure path:line: `cmd`: reason on
stderr plus a Script: N command(s) failed summary — but nothing reached the
process status. A driver that surfaces output only on a non-zero return code
never showed any of it to the operator.

That is worse than a missing message. A failed command leaves the previous state
in place instead of aborting, so the :screenshot after a failed :color is
still written, with the old colour. Both the run and the figure look fine. The
issue reports exactly this: two montages rendered byte-identical because every
:color in one of them had failed, and the wrapper reported success.

The fix

A batch run exits 1 if any command failed, 0 only if all succeeded.

$ molterm --script repro.mt --no-tui; echo "exit=$?"
...
Saved 400x300 to A1_blue.png
<stdin>:5: `:color firebrick`: Unknown color/scheme: firebrick | Available: ...
Saved 400x300 to A2_after_invalid_name.png
Script: 1 command(s) failed
exit=1

The script still runs to completion — only the status changes. --strict
already existed and remains the way to stop at the first failure; the issue
lists it as an optional extra, so this PR just documents it better rather than
adding a second spelling.

Scoped to batch runs. An interactive --tui session keeps its own exit status,
since there the script is setup for a session rather than the run itself.

Docs

--help grew an Exit status: section (0 / 1 / 2), and README + SCRIPTING.md
both spell out why the code matters — that a failed command leaves a
plausible-looking wrong figure behind, so || exit in a driver is not optional.

Verification

Five new assertions in tests/test_script.sh, driven through the real binary:
clean script exits 0; a failed command exits 1; the script still runs on past
the failure; a failure anywhere counts, not just the last command; --strict
still exits 1. Full suite green.

The issue's exact repro now exits 1 while still writing both PNGs — the
screenshots remain byte-identical, which is the documented non-strict behaviour;
the point is that the return code now says so.

🤖 Generated with Claude Code