fix(appcontainer): default sandbox cwd to a granted path instead of NULL

[caarlos0]

📖 Description

Sandboxed shells were starting on C:\ instead of the intended working directory on the Windows AppContainer + DACL (and BaseContainer) backends.

Root cause: when process.cwd was empty, both Windows runners passed a NULL current directory to CreateProcessW, so the child inherited the host process's cwd. Under a deny-by-default AppContainer token that directory is often unopenable, and the kernel then silently resets the child to the drive root (C:\) instead of failing the launch. This surfaced most via the in-process Rust SDK, whose host cwd is the caller's process directory rather than a granted path (the Node SDK happened to inherit the executor's cwd, which is usually the granted workspace).

Fix: mirror the macOS Seatbelt backend, which already avoids this trap. Add ExecutionRequest::resolved_working_directory() — explicit working_directory wins, else the first readwrite path, else the first readonly path — and use it in both Windows runners. An unset cwd now defaults to a policy-granted path (first readwrite/readonly) instead of NULL. The resolver only picks the path; it does not verify the directory exists, so an explicit-but-ungranted (or missing) cwd still fails loudly — parity with Seatbelt — rather than silently landing on C:\.

Scope note: only the AppContainer/BaseContainer family was affected. Seatbelt already had an equivalent resolver; the micro-VM backends (NanVix/Hyperlight) reject a working directory by design; the Linux/WSL backends fall back to / / the container root.

🔗 References

🔍 Validation

• New unit tests for resolved_working_directory() (explicit wins, first readwrite, first readonly, none) — cargo test -p wxc_common passes (397 tests).
• cargo check and cargo clippy -- -D warnings on appcontainer_common for x86_64-pc-windows-msvc — clean.
• cargo check -p mxc-sdk and cargo fmt --all -- --check — clean.
• Full PR CI green across all Windows/Linux/macOS build, lint, and SDK jobs.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue
• Updated documentation (if applicable)
• Updated Copilot instructions (if build, architecture, or conventions changed)
• If this PR changes Cargo.lock, the dependency-feed-check check passes (see docs/pull-requests.md)

📋 Issue Type

• Bug fix
• Feature
• Task

[Copilot]

Pull request overview

This PR fixes an AppContainer/BaseContainer Windows behavior where an unset working directory resulted in passing NULL to CreateProcessW, causing the child process to inherit the host cwd and (when inaccessible under a deny-by-default token) silently start at C:\. It adds a shared resolver on ExecutionRequest to choose a policy-granted cwd when the request doesn’t specify one, and uses it in both Windows runners.

Changes:

• Add ExecutionRequest::resolved_working_directory() to derive an appropriate cwd (explicit wins; else first readwrite path; else first readonly path; else None).
• Use the resolver in both AppContainerScriptRunner and BaseContainerRunner when building the CreateProcess* working-directory argument.
• Update the schema documentation example to mention the new defaulting behavior.

Show a summary per file

File	Description
src/core/wxc_common/src/models.rs	Adds ExecutionRequest::resolved_working_directory() and unit tests covering precedence and empty-policy behavior.
src/backends/appcontainer/common/src/base_container_runner.rs	Uses the resolved working directory when passing the cwd pointer to Experimental_CreateProcessInSandbox.
src/backends/appcontainer/common/src/appcontainer_runner.rs	Uses the resolved working directory when passing the cwd pointer to CreateProcessW.
docs/schema.md	Updates the config example comment for process.cwd to reflect defaulting behavior when omitted.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 2
• Review effort level: Low

[Copilot]

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Medium

[bbonaby]

@Caarlos, how much work is this to add in? And do you think it's necessary