Runtime: exit with non-zero status when uncaught TypeError aborts execution #511

Followup to #462 / #455 DX thread.

After #462, undefined.foo correctly prints a node-shaped TypeError: Cannot read properties of undefined (reading 'foo') and stops execution. But the process exit code is 0, where Node exits with 1.

Repro

const obj: any = undefined;
const x = obj.foo;

$ perry compile test.ts -o test && ./test; echo "exit=$?"
TypeError: Cannot read properties of undefined (reading 'foo')
exit=0

$ node --experimental-strip-types test.ts; echo "node exit=$?"
TypeError: Cannot read properties of undefined (reading 'foo')
    at Object.<anonymous> (test.ts:3:15)
    ...
node exit=1

Why this matters

CI scripts that gate on exit status (./my-app && echo OK) treat the thrown TypeError as success. Production process supervisors (systemd, PM2, k8s) won't restart a crashed Perry binary because it "exited cleanly." This silently subverts every standard ops practice for handling unhandled errors.

Where this hooks in

crates/perry-runtime/src/object.rs::js_throw_type_error_property_access (the v0.5.526 helper). Today it likely calls something like eprintln! + std::process::exit(0) or returns normally and lets the program continue past the throw site. Should be std::process::exit(1) (or abort()).

Same fix should apply to any other js_throw_* runtime helpers — audit pass needed:

$ grep -rn "fn js_throw_" crates/perry-runtime/src/

Should also confirm that user-level throw new Error(...) without a try/catch exits non-zero — otherwise this is a category of bugs, not a single fix. (If Perry today exits 0 on any uncaught throw, this issue covers all of them.)

Refs: #455, #462 (closed).