[Bug]: Target snapshot does not expose the working directory used by relative file transfers #879

Describe the bug

winapp target snapshot sandbox --json exposes capabilities.managedRoot (observed as C:\WinApp) but does not expose the managed working directory used for relative file-transfer destinations (observed as C:\WinApp\work). An agent can incorrectly assume the reported managed root is the directory where its uploaded file lives.

This is a metadata/discoverability gap, not a demonstrated file-copy failure. target push already documents destinations as relative to the managed work area and the original report said its output printed the correct resolved destination.

Agreed scope: expose workRoot in the target snapshot, derived from the existing authoritative path-resolution logic. Do not bundle launcher/app PID discovery, activation changes, or transfer redesign into this issue.

To Reproduce

1. Run:

winapp target snapshot sandbox --json

2. Observe capabilities.managedRoot: "C:\\WinApp" and no separate workRoot field.
3. Compare with the documented behavior of:

winapp target push sandbox .\probe.txt probe.txt --json

A relative destination is resolved under the managed work area, reported in the original live feedback as C:\WinApp\work\probe.txt, not directly under C:\WinApp.

Independent validation: live snapshots on CLI 0.6.3-prerelease.52 confirmed that workRoot is absent. Six targeted guest-path/snapshot tests passed at source revision 2e307c7e8e648a1906205241148de20bcf12f7ab. These passing tests confirm existing contracts; they do not constitute a new end-to-end push reproduction. No fresh push was performed for this investigation because another agent held the shared sandbox test slot.

Expected behavior

The snapshot should report the absolute managed working directory separately from the managed root, so an agent can determine where relative transfer paths resolve without guessing or performing a probe upload.

Recommended implementation and acceptance criteria:

• Expose an unambiguous workRoot in snapshot JSON alongside the relevant target path metadata, following existing output conventions.
• Derive it using the same guest-reported root and path-resolution mechanism used by relative transfers. Do not hardcode C:\WinApp\work or add a second independently maintained path rule.
• Preserve the distinction between managedRoot and workRoot; do not change where relative transfers go.
• Do not fabricate a working root when the guest/root is unavailable. Preserve read-only snapshot behavior: reporting metadata must not create/start/reconnect or otherwise prepare a target.
• Add failing regression coverage for the newly reported field, agreement with relative-transfer resolution, a nondefault guest root, and missing/unavailable root information.
• Update only the relevant canonical snapshot/transfer documentation and affected generated surfaces.
• Validate with a harmless uniquely named upload/read-only path check when an exclusive sandbox test slot is available; clean up only the exact probe artifacts. Unit tests must not reset or alter the shared sandbox.

The separate observation that a tracked package-launcher PID differs from the real UI app PID is explicitly out of scope; existing output labels the launcher correctly.

Screenshots

N/A. This is structured target metadata.

OS Version and details

Installed CLI 0.6.3-prerelease.52; native ARM64 Windows host and managed Windows Sandbox. Live snapshot evidence was collected in both disconnected and connected states. Source inspected/tested at 2e307c7e8e648a1906205241148de20bcf12f7ab.