Improve error messages from VM (exec path)

[appcypher]

Summary

When a command fails inside a sandbox, the user gets no explanation — just a raw exit code. For ephemeral sandboxes (the default), the sandbox is cleaned up immediately, so there are no logs to inspect either. We should surface exec errors clearly and point users to logs when available.

Current behavior

$ msb run ubuntu -- doesnotexist
$ echo $?
255

The user has no idea what happened. The agentd inside the guest does capture the actual error (e.g., ENOENT — "No such file or directory") but only sends back ExecExited { code: -1 } through the protocol. The error description is logged inside the sandbox directory, which is immediately deleted for ephemeral runs.

For named sandboxes, logs exist at ~/.microsandbox/sandboxes/<name>/logs/ but the CLI doesn't tell the user where to look.

Proposed behavior

Surface exec errors through the protocol

Extend ExecExited (or add a new message type) to carry an optional error description alongside the exit code. The CLI would print the error and still relay the exit code:

$ msb run ubuntu -- doesnotexist
error: exec failed: No such file or directory (os error 2)
$ echo $?
127

Point users to logs for named sandboxes

When a named sandbox command fails, print a hint with the log path:

$ msb run --name my-sandbox ubuntu -- doesnotexist
error: exec failed: No such file or directory (os error 2)
hint: see logs at ~/.microsandbox/sandboxes/my-sandbox/logs/

[majiayu000]

Hi, I've been looking into this and traced the root cause.

Proposed approach: 1. Find the ExecExited variant/struct in the codebase (likely in an error or message types module). 2. Add an error description field to ExecExited. 3. Populate the error description from VM stderr/exit info where ExecExited is constructed. 4. Add log path hints to the error message output. 5. Update any Display/formatting impls. 6. Add or update tests for the improved error messages.

I'll open a draft PR shortly. Happy to adjust based on your preference.