Error messages replace virtual /tmp paths with <path>, and write errors always say "No such file or directory"

just-bash version

3.6.0

Reproduction

nl /tmp/t/missing.txt

tee /ro/f.txt <<< hi
sed -i 's/x/y/' /ro/f.txt

How you run it

The first script runs with new Bash({ files: { "/tmp/t/n.txt": "n\n" } }).

The second runs on a filesystem whose /ro refuses writes the way a read-only mount does:

import { Bash, InMemoryFs } from "just-bash";

class ReadOnlyBranch extends InMemoryFs {
  async writeFile(path, ...rest) {
    if (path.startsWith("/ro/")) {
      throw Object.assign(new Error(`EROFS: read-only file system, open '${path}'`), { code: "EROFS" });
    }
    return super.writeFile(path, ...rest);
  }
}

const bash = new Bash({ fs: new ReadOnlyBranch({ "/ro/f.txt": "x\n" }) });

Expected behavior

nl: /tmp/t/missing.txt: No such file or directory

hi
tee: /ro/f.txt: Read-only file system

and an error from sed -i that says the file system is read-only.

Actual behavior

nl: ENOENT: no such file or directory, open '<path>'

hi
tee: /ro/f.txt: No such file or directory
sed: /ro/f.txt: No such file or directory

Two things here:

1. <path>. It comes from the host-path sanitizer. That makes sense for OverlayFs/ReadWriteFs, where a message could leak a real host path. With InMemoryFs or a custom IFileSystem, though, /tmp/t/missing.txt is the script's own virtual path, and hiding it makes the message useless. Maybe sanitize only paths that come from a host-backed filesystem, or let embedders turn it off?
2. Write errors. This is the write-side version of #570: tee and sed -i print "No such file or directory" whatever the error was, so a read-only file looks like a missing one.

Environment

• Runtime (Node, Bun, browser, CLI): Node
• Runtime version: 26.8.2
• Operating system: macOS 15
• Bundler or framework, when relevant: none