bug(cli): sandbox upload from a WSL2 /mnt/<drive> path writes files with correct size but all-NUL content

[moka-ayumu]

User Story

As a Windows user running the OpenShell CLI inside WSL2,
I want openshell sandbox upload to copy files from the Windows filesystem (/mnt/c/...) into a sandbox byte-for-byte,
so that the files in the sandbox match the files on the host.

Problem Statement

When the local path passed to openshell sandbox upload is on a WSL2 Windows drive mount(/mnt/c/...), every uploaded file keeps its original name and size, but its content is all zero bytes (\0). The command still reports "✓ Upload complete" and exits 0.

The same files upload correctly when the source is a WSL-native path (e.g. /tmp).

Impact / Why This Matters

• Silent data corruption: the upload reports success, so users only find out later that the files in the sandbox are NUL-filled.
• On Windows + WSL2, projects usually live on the Windows drive (/mnt/c/...), so the common "upload my project" workflow is affected.
• Current workaround: copy the files to a WSL-native directory first and upload from there.

Acceptance Criteria

• Files uploaded from a /mnt/ path have content identical to the source.
• If a source file cannot be read correctly, the upload fails with a non-zero exit code instead of reporting "Upload complete".

Reproduction Steps

1. In WSL2, create a test file on the Windows drive:
   mkdir -p /mnt/c/Users//ostest && printf 'hello\n' > /mnt/c/Users//ostest/a.txt
2. openshell sandbox create --name repro --detach
3. openshell sandbox upload repro /mnt/c/Users//ostest /tmp/up1
4. openshell sandbox exec -n repro --no-login-shell -- od -c /tmp/up1/ostest/a.txt
   → file is 6 bytes, all NUL (expected "hello\n")

Environment

• OpenShell: 0.1.0
• OS: Windows 11 + WSL2 (Ubuntu 24.04)
• Runtime: MicroVM (openshell-driver-vm 0.1.0)

Logs

$ openshell sandbox upload repro /mnt/c/Users/<user>/ostest /tmp/up1
Uploading /mnt/c/Users/<user>/ostest -> sandbox:/tmp/up1
✓ Upload complete

$ openshell sandbox exec -n repro --no-login-shell -- od -c /tmp/up1/ostest/a.txt
0000000  \0  \0  \0  \0  \0  \0
0000006

[kvnloo]

Because the destination file has the correct size but all-zero content, I would first isolate whether corruption happens before or after the upload protocol boundary.

A small diagnostic test could read the exact same source through the CLI's local-file code path and record:

• expected byte length;
• first/last small byte sample or test hash;
• number of non-zero bytes read.

Run that against:

/tmp/test-file

and:

/mnt/c/.../test-file

before contacting a sandbox.

If the /mnt/c read is already zero-filled, the fix belongs in the local WSL/Windows filesystem read path.

If the local bytes are correct, replay those same in-memory bytes through upload and inspect the receiver/write path.

For the final regression I would use binary content containing zeros as well as non-zero bytes and assert byte-for-byte equality, not just file size.

Most importantly, a short/failed/corrupt source read must make sandbox upload fail rather than print Upload complete.