Prevent `xmd run` filesystem operations from escaping the working directory

[taras]

Story

As an XMD user, I want a filesystem operation to remain inside its authorized
root even when another process replaces a directory or symbolic link during the
operation.

Example attack

Suppose a document is allowed to write only inside /project/output:

1. XMD checks that /project/output/report.txt is inside the allowed root.
2. Before XMD opens the file, another process replaces output with a symbolic
   link to a directory outside /project.
3. A vulnerable implementation follows the replacement and writes outside the
   authorized root.

Checking a path and using it as two separate filesystem actions creates this
race. The authorization must still hold when the operating system performs the
access.

Required guarantee

The guarantee differs by filesystem provider and must be stated honestly.

xmd workflow

Workflow file effects address logical paths inside the provider-owned DOFS
Workspace. Every operation is authorized against that logical namespace. It
does not validate a host path and then perform an unguarded host-filesystem
operation, so replacing a host symbolic link cannot redirect the access.

xmd run

The host-filesystem provider must prevent a path replacement between
authorization and access for every supported Deno, Node, Bun, and compiled
runtime adapter. The implementation must use a mechanism whose guarantee holds
at access time, not another pre-access path check.

If a runtime or platform cannot provide the strong guarantee, XMD must either
refuse the affected operation or document the narrower supported boundary. It
must not present a weaker implementation as equivalent protection.

Agent read-only materialization belongs to #302. Its containment does not prove
that ordinary xmd run filesystem effects close this race.

Acceptance

• Architecture and the executable-MDX threat model explain the attack in
  user-recognizable terms and distinguish Workflow from host-filesystem
  protection.
• A Workflow operation cannot escape through host path replacement because its
  authoritative namespace is provider-owned.
• The selected host mechanism and exact guarantee are recorded for Deno, Node,
  Bun, and the compiled binary on each supported platform.
• A runtime that cannot enforce the guarantee refuses the operation or clearly
  states its narrower boundary.
• Deterministic tests pause between authorization and access, replace the path,
  and prove that every supported host implementation refuses or remains inside
  the root.
• Negative controls demonstrate that the same replacement escapes a deliberately
  vulnerable validate-then-open implementation.
• Runtime adapters install the mechanism through contextual APIs; shared
  production modules do not detect the active runtime.

Security boundary

This issue prevents filesystem effects from escaping their authorized root by a
concurrent path replacement. It does not provide:

• Agent-generated XMD or Agent-provider sandboxing;
• native command containment;
• changes to <File> authoring forms; or
• a guarantee about operating-system facilities outside the selected
  filesystem provider.

Related work

• PR 📝 Specify retained workflow Workspaces #358 establishes the Workflow Workspace provider boundary.
• Run workflow Agents through XMD-mediated observations #302 consumes the read-only materialization guarantee for Agents.
• ✨ Compose and certify the supervised adversarial implementation workflow #181 is the end-to-end workflow delivery that leaves this host-filesystem
  hardening as independent work.