msb: acq exec runs in the guest default cwd instead of the primary workspace #421

What happens

On the msb backend, acq exec NAME -- CMD runs CMD in the guest's default working directory instead of the sandbox's primary workspace. Anything that depends on starting in the repo — the documented devenv approval flow being the first casualty — fails:

$ acq --backend msb exec msb-irr -- bash -lc 'direnv allow && direnv exec . true'
direnv: error .envrc file not found

The sandbox is fine: /var/lib/acq/workspace holds the right path, the workspace mount is present in the guest, and .envrc exists there. acq shell and acq run on the same sandbox land in the repo as expected.

Expected

acq exec starts in the primary workspace, matching the sbx backend and msb's own shell/run. The docs promise this: CONCEPTS.md says the agent starts in the primary workspace, and downstream kit docs build their one-shot devenv approval on "acq exec starts in the primary repo".

Root cause

acq_backend_run (acq.backends/msb.sh, backs the exec verb) builds its msb exec invocation with -u agent -e HOME=… plus the ssh-agent sock and replayed kit env — but no -w. Every other session path resolves the recorded workspace and passes -w "$ws": _acq_msb_shell_exec and acq_backend_attach both read ACQ_MSB_WORKSPACE → /var/lib/acq/workspace → /home/agent fallback. exec is the only session verb that skips that resolution, so it inherits msb's default cwd.

Proposed fix

Resolve ws in acq_backend_run exactly as _acq_msb_shell_exec does (the lookup is already factored to take a pre-resolved WS argument, so it could be extracted or reused) and add -w "$ws" to both branches. No behavior change on sbx, which already starts exec in the workspace.

Observed on msb 0.6.15, acq main, macOS host. Workaround until then: prefix the command with an explicit cd into the workspace path.