Uncaught runtime EXCEPTION exits with code 1 — indistinguishable from a compile error; should get a distinct negative exit code

[borisbat]

Current behavior

An uncaught runtime exception (panic, stack overflow, …) in a script run via daslang file.das prints EXCEPTION: <message> to stderr and exits with code 1 — the same exit code as a compile error:

$ daslang panic_probe.das        # def main { panic("boom") }
before
EXCEPTION: boom
 at .../panic_probe.das:6:4
$ echo $?
1

$ daslang synerr_probe.das       # a file with a syntax error
$ echo $?
1

Same under -jit.

Problem

A wrapper (CI script, test harness, benchmark driver) cannot distinguish "the script failed to compile" from "the script compiled, ran, and died at runtime". Worse, the diagnostic detail is stderr-only, so the common OUT="$(daslang ... 2>/dev/null)" capture pattern swallows it entirely — under set -e the wrapper aborts with no output at all and no way to tell what happened.

Real-world cost: a dasLLAMA parity harness silently produced empty output three runs in a row; the actual cause was a stack overflow at model load (a program root missing options stack), invisible because the EXCEPTION line went to a discarded stderr and exit 1 read as a generic failure.

Proposal

1. Distinct exit code for uncaught runtime exceptions — a negative value (e.g. -2), keeping compile errors at their current code. Windows already reports native crashes as negative codes (-1073741819 for AV), so "negative = died at runtime" is a natural convention; documenting the chosen value alongside the existing exit-code table is enough for wrappers.
2. Keep printing the exception + location on exit (current behavior is good) — consider echoing a one-line EXCEPTION marker to stdout as well, so stderr-discarding capture patterns still see evidence of the death.

Verified on Windows x64, current master.