The Problem

When running exec from a WSL2 gateway to a Windows node, the gateway attempts to stat() the workdir path using its own (Linux) filesystem before sending the command to the node.

If the path is not perfectly mirrored or is an absolute Linux path (e.g., /mnt/c/...), the gateway fails to resolve it, leading to a fall-through or mangled path that the Windows node rejects with SYSTEM_RUN_DENIED: approval requires an existing canonical cwd.

Why this is a bug

The node and gateway are separate entities. The gateway should not be performing filesystem validation/resolution on workdir intended for a remote node host.

Repro Case

1. Gateway (WSL2) attempts exec host=node workdir='/home/user/clawd' command='notepad.exe'.
2. Gateway checks stat('/home/user/clawd') (valid locally).
3. Windows node receives command, attempts to resolve path, and panics because /home/user/clawd does not exist on Windows, triggering the hardening error.

Expected Behavior

exec host=node should pass the provided workdir string as-is to the node, or default to . (relative) on the node's filesystem, bypassing gateway-side resolution entirely.