[cli] exit() in embedded AILANG escapes as a raw panic into the host (internal/embed)

[sunholo-voight-kampff]

Found by the iteration-192 evaluator while reviewing #607 (PR #690), and confirmed first-party.

The gap

exit() raises a *eval.EvalExitCode sentinel panic (internal/effects/io.go:145). Two consumers recover it:

• cmd/ailang/main_run_exec.go:552-568 — the single-file run path
• cmd/ailang/run_helpers.go (recoverBatchItemExit) — the batch path, added by [cli] Batch mode: a module calling exit() inside a ba... #607

internal/embed — the sanctioned dashboard → compiler bridge — does not. Engine.Call (embed.go:237) and Engine.CallPreserveFloats (embed.go:314) call runtime.CallEntrypoint directly.

Measured:

grep -c 'recover()' internal/embed/embed.go   -> 0
grep -c 'recover()' cmd/ailang/run_helpers.go -> 2   # known-positive control, same instrument
test -f internal/embed/embed.go                -> YES # scope control

So an embedded module that calls exit() panics the host process with a raw Go stack — the same defect class as #607, one layer down. For a long-lived host (the dashboard/observatory), that is a crash rather than a bad exit code.

Why it was not fixed in #690

#607 is specifically about ailang run --batch, and the call-site census there was correctly scoped to executeModuleEntrypoint (exactly two sites, both now recovered). runtime.CallEntrypoint is the broader primitive, and widening the fix into the embed layer needs its own decision: an embedding host has no os.Exit semantics to map onto, so the right contract is probably to surface exit(N) as a typed error to the caller rather than to recover-and-ignore it.

Suggested acceptance

• Decide the contract: typed error (e.g. ErrProgramExit{Code}) returned from Call/CallPreserveFloats, not a panic.
• A test that embeds a module calling exit(1) and asserts the host survives with that typed error.
• Per the mutation discipline: neutering the new recover must red that test.

Related: #607, PR #690.

[sunholo-voight-kampff]

Fixed — V1 mission iteration 197, PR #705 → squash 20d538a43.

Reproduced first-party at HEAD before fixing, frame-for-frame as filed: effects/io.go:145 → runtime/entrypoint.go:112 → embed.(*Engine).Call at embed.go:237, host test binary dead.

Contract decided: exit(N) is surfaced as a typed *embed.ExitError{Code: N} from Call, CallPreserveFloats and transitively CallJSON. exit(0) is an ExitError too, not a nil error — unlike the CLI batch path, which owns a process and maps exit(0) to success. A nil error here would be indistinguishable from a function returning unit, discarding information the caller cannot recover.

runtime.CallEntrypoint deliberately stays panic-based: the CLI needs the sentinel to reach its own recover to map onto os.Exit. Census re-derived independently by the evaluator — exactly 4 call sites repo-wide, 2 CLI (already covered) + 2 embed (now wrapped).

Mutation drill, one per branch, each asserted LANDED (sha256) and BUILDS (go build rc=0) before its result was read: exit-mapping, re-panic and passthrough branches each red only their own arms; unwiring either call site leaves the other site's arm passing — so the two entry points are pinned independently, not assumed equivalent. Inverse arm: both guards removed and exit_test.go deleted → internal/embed is rc=0, 60 PASS / 0 FAIL. The defect shipped entirely undetected by the existing suite.

Gate 3b GREEN: 21 checks, pending=0, zero not-green, 4/4 required, with test-windows and all three Build legs named rather than assumed.

Two residuals declared in code: Engine.Eval (UNINFORMATIVE — GAP-5) and GetCallValue/GetCallValueN (unwrapped handles; verified harmless for the in-evaluator use).

A third residual the evaluator found and I confirmed first-party is filed separately as #706: no host special-cases *embed.ExitError, so exit(0) in a serve-api route handler now returns HTTP 500. Not a regression — that path previously crashed the whole process.