e2b: filesystem users do not affect relative-path resolution

[sweetcornna]

What happened

The official E2B filesystem contract says the user option affects both ownership and resolution of relative paths. Dormice validates and forwards the selected user to the container process, but resolves every relative path against /home/user before doing so.

Reproduction:

1. Start a Docker sandbox through e2b 2.31.0.
2. Run await sandbox.files.write('root-relative.txt', 'x', { user: 'root' }).
3. As root, check /root/root-relative.txt and /home/user/root-relative.txt, and inspect the path returned by write.

Expected: The file and returned path are /root/root-relative.txt, matching the selected user's home directory.

Actual: Dormice creates a root-owned /home/user/root-relative.txt and reports that path. The same user-independent resolution is used by read, list, stat, mkdir, rename, remove, and streaming file operations.

Impact: E2B workloads using relative paths as root read or modify a different location from the official service. They can miss expected files or overwrite the default user's files.

Relevant code and contract:

• packages/shared/src/files.ts:39-68 defines the shared resolver and unconditionally prefixes relative paths with /home/user/.
• packages/server/src/executor/docker.ts:818-876 resolves write/read paths separately from forwarding user; 984-1162 repeats this for unary filesystem operations.
• packages/server/src/e2b/envd/files.ts:337-367 uses the same resolver for the uploaded file path returned to the SDK.
• e2b 2.31.0 FilesystemRequestOpts.user documents that the option affects relative-path resolution and ownership.

dor doctor output

Not applicable — this is an E2B compatibility behavior in the Docker executor, not a host-readiness failure.

Environment

• Dormice commit: 4417ae14938273f5d937c476cf7cdc57e22e53a5
• SDK: e2b 2.31.0
• Executor: Docker + gVisor
• Verification: SDK contract trace and Docker path/identity trace