💥 Make TypeScript eval failures fatal like checked exec failures

[taras]

Story

As an executable-document author, I want a failing TypeScript or JavaScript
eval block to stop the run like a failing exec block, so choosing the
preferred implementation language does not weaken the document's failure
semantics.

Current behavior

PR #442 made a checked shell-command failure stop the run. A TypeScript eval
throw still follows the ambient error mode. At a text root without <Output>,
that mode is print, so the failure becomes a rendered comment, later work
runs, and the CLI exits 0.

PR #308 exposed the difference in an operational document. Removing its
<Output> region left shell failures fatal but turned TypeScript refusal paths
into successful runs containing error comments. Its 37-step regression then
failed in four refusal groups.

Representative contrast:

```bash exec
exit 1
```

AFTER

stops before AFTER and exits nonzero, while:

```ts eval
throw new Error("refused")
```

AFTER

can render the diagnostic, continue through AFTER, and exit 0 under the
root's printing mode.

That ordering is backwards for repository-authored executable documents, whose
style guide prefers Markdown, then JavaScript/TypeScript, then Bash/SH. Moving a
decision from shell into TypeScript must not turn a refusal into successful
completion.

Contract

A failure of a JavaScript or TypeScript block whose terminal modifier is
eval is a checked code-execution failure, on the same terms as a nonzero
exec result:

• it fails the current document execution regardless of an ambient printing
  error mode;
• later blocks and sibling content do not begin;
• execute() completes with Err and the CLI exits nonzero;
• its diagnostic is observed and displayed at most once;
• the original failure remains available as the cause of the block-level
  diagnostic; and
• cleanup and cancellation retain their existing structured-concurrency
  behavior.

This applies to failures produced while compiling, importing, or evaluating an
eval block. A successful block and its bindings/output are unchanged.

<Output> remains the construct for selecting and buffering a region's output;
an author no longer needs to add it solely to prevent a TypeScript refusal from
being converted into successful document output.

Boundaries

• Do not make every authored ErrorSegment fatal.
• Do not change ordinary function-component failure semantics established by
  Make function-component failures fail-fast by default with explicit collection boundaries #249.
• Do not change 🔒 Let the region decide a projected content failure #446's rule that the author of a region owns failures from
  content projected into it.
• Do not change durability or Files-infrastructure precedence.
• Do not add a TypeScript-specific marker or require authors to wrap eval
  blocks in <Output>.

The implementation should use the common checked code-block failure boundary,
not duplicate shell-specific fatality in the eval compiler or runtime adapter.

Acceptance criteria

• A root-level ts eval throw fails the execution, exits nonzero through the
  CLI, emits one diagnostic, and never runs a following marker.
• The same failure cannot be downgraded to successful completion by an ambient
  printing region.
• A compile/import failure has the same outcome as an evaluation-time throw.
• The equivalent failed exec scenario remains unchanged as the paired
  control.
• Successful JavaScript and TypeScript eval blocks retain their current value,
  binding, output, journal, and replay behavior.
• Existing function-component, projected-content, error-observation,
  cancellation, durability, and Files-fatal suites remain green.
• architecture.md and specs/executable-mdx-spec.md describe checked
  code-block failures consistently across exec and eval.

Evidence

Add one end-to-end matrix that runs the same document shape through shell and
TypeScript terminals and distinguishes:

• completion Err versus Ok containing a rendered diagnostic;
• following content absent versus present;
• exactly one diagnostic; and
• CLI exit 1 versus 0.

Mutation-check the TypeScript case by restoring ambient settlement through
raise(); it must turn red rather than passing from output text alone.

Related work

• 🚿 Stream a foreground command and keep what the boundary received #442 — foreground command output and checked exec failure.
• 🔒 Let the region decide a projected content failure #446 — region ownership for projected content failures.
• 💥 Fail a root document on an uncaught failure without requiring <Output> #453 — uncaught text-root failure settlement.
• ✨ Bootstrap an npm package as a real xmd run #308 / Bootstrap npm packages as a real xmd run: elicit the OTP #276 — the npm bootstrap document that exposed the asymmetry.
• Make function-component failures fail-fast by default with explicit collection boundaries #249 — function components already fail fast by default; this issue does not
  reopen that contract.

[taras]

Closing as already delivered. The premise was measured on a stale base.

d75ee90 (#457, implementing #453) merged after 9010557 (#448), and PR #308 — the document this issue was written from — is based on 9010557. On that tree a ts eval throw does print and exit 0, which is what I reported and what this issue records as current behavior. On main it does not.

Measured on 6a777dd:

scenario	bash exec	ts eval
text root, no <Output>	exit 1	exit 1
inside <Output>	exit 1	exit 1
inside <PrintErrors>	exit 0, printed	exit 0, printed
compile failure (syntax error)	—	exit 1
import failure (unresolvable specifier)	—	exit 1

This issue's own representative contrast now behaves as the contract requires:

$ deno task xmd run i461.md
refusing to continue
EXIT=1

AFTER does not run, one diagnostic is emitted, and the CLI exits nonzero — without <Output>.

Every acceptance criterion holds, including the two called out separately (a compile/import failure has the same outcome as an evaluation-time throw). <PrintErrors> recovers exec and eval identically, which is the authored construct this issue's Boundaries explicitly preserve rather than a remaining asymmetry.

Mechanism, for the record: checkedCommandFailure (packages/core/src/expand.ts:1067) upgrades print → output for a nonzero command, with the comment "a root that merely prints by default does not get to call the run a success." #457 generalized that principle to the root itself, so an undecided eval failure settles on the same terms. The language hierarchy was never inverted on main.

Separately, PR #308's regression suite passes all 37 steps on main with its <Output> region removed — the four refusal groups that failed on the old base no longer depend on it.