🐛 <TempDir> turns <Output> failures into success and continues later effects

[taras]

Problem

A wrapping <TempDir> silently changes the failure semantics of an enclosing
<Output> region. An ordinary failure inside the temporary directory becomes a
printed error, expansion continues both inside and after <TempDir>, the content
rendered around the failure is discarded, and the document completes
successfully.

That defeats <Output>'s fail-closed contract. In an operational document, a
failed preview inside <TempDir> can therefore be followed by an elicitation or
an external mutation such as publish.

This blocks the Markdown-first npm bootstrap in #276 / #308. Nesting every later
step behind another <If> is not a safe substitute: a future sibling silently
reopens the path, and the failed stage's stdout and rendered refusal remain
unavailable.

Reproduction

Reproduced from source at main commit
a1c196c18cd766267a9398348422517abad08cb3:

<Output>
<TempDir>

```bash exec
echo FIRST >> /tmp/xmd-tempdir-trace
echo stdout-of-failing
exit 1
```

TEXT-AFTER-FAILURE

```bash exec
echo SECOND >> /tmp/xmd-tempdir-trace
```

</TempDir>

```bash exec
echo OUTER >> /tmp/xmd-tempdir-trace
```

</Output>

Run with:

deno task xmd run /tmp/tempdir-failure-repro.md --raw --no-secret-detection

Observed result:

• exit status is 0;
• rendered output is only one <!-- ERROR: Command failed (exit 1) ... -->;
• stdout-of-failing and TEXT-AFTER-FAILURE are absent;
• /tmp/xmd-tempdir-trace contains FIRST, SECOND, and OUTER.

Replacing <TempDir> with <If condition={true}> is the control. It exits 1,
preserves stdout-of-failing, and the trace contains only FIRST.

Contract conflict

#309 made continuation after an ordinary failure explicit and scope-local; the
current vocabulary is <PrintErrors> / printErrors(fn). <TempDir> declares
printErrors(...) internally, so merely asking for a working directory opts the
author into recovery without an explicit capture boundary.

The resulting behavior conflicts with specs/executable-mdx-spec.md §6.9:

• an error in an <Output> region fails the run;
• nothing after it begins; and
• a failing visible region preserves what it rendered before the failure.

There is an uncovered interaction with §6.11 and TD14. They preserve the older
rule that an ordinary <TempDir> failure is printable under the root's default
printing mode, but do not cover <TempDir> inside <Output>. The fix must make
the precedence explicit and update §6.11 rather than leaving contradictory
general statements.

The implementation path is visible in
packages/core/src/components/TempDir.ts: wrapping form calls content() from a
component marked with printErrors. The projection runs to completion under
the printing boundary, then ContentExpansionFailure replaces the projection
with only its error segment, accounting for both continuation and lost output.

Required behavior

• <TempDir> changes the contextual working directory and owns cleanup; it does
  not implicitly opt its content into failure recovery.
• Inside <Output>, the first ordinary failure in a wrapping <TempDir>:
  • preserves visible output produced before and by the failing command;
  • fails the document;
  • prevents later content inside <TempDir> from starting; and
  • prevents siblings after <TempDir> from starting.
• An author can still request continuation explicitly with <PrintErrors> at
  the intended scope.
• Temporary-directory cleanup still completes on success, failure, and
  cancellation.
• Root documents without <Output> retain their documented default printing
  behavior unless an explicit architecture amendment says otherwise.
• Add a regression that asserts exit outcome, rendered prefix, an internal
  side-effect probe, an external sibling probe, and cleanup. Keep the <If>
  control or an equivalent discriminating case.
• Update specs/executable-mdx-spec.md §6.9 and §6.11 together with the fix.

Related work

• 💥 Make <Output> fail fast and rename failure capture to CaptureErrors #309 selected fail-fast <Output> and explicit recovery.
• 💥 Build the error propagation and partial output rules #318 implemented error propagation and partial output but did not cover this
  <TempDir> interaction.
• The previously observed <Elicit> partial-output behavior may share the same
  projection/failure boundary, but it is not required to close this issue unless
  the same fix changes it.