[Bug]: Sandbox screenshot text reports a guest path and help misdescribes composite output

### Describe the bug

Two screenshot reporting problems were independently reproduced on installed CLI `0.6.3-nmetulev-devtools-extraction.81`:

1. **Plain output reports an unusable guest staging path.** The command succeeds and delivers the requested screenshot to the host, but stdout prints a wrapped `C:\WinApp\artifacts\...` path instead of the host destination. JSON output reports the correct host path.
2. **Help describes the wrong output format.** Installed help promises separate image files for multiple windows; default captures actually produce a single labeled composite containing the target and owned popup windows, including when targeting the main HWND explicitly.

Agreed scope: correct plain host-path reporting and help/documentation describing existing composition. **Do not change capture composition, remove owned windows/tooltips, add capture modes, or weaken foreground/input safeguards.** Tooltip inclusion itself was not established as a defect.

### To Reproduce

Use a connected managed Windows Sandbox with Daylight (public WinUI demo: https://github.com/nmetulev/daylight) on its planner. Discover the current PID/main HWND independently:

```powershell
winapp --version
winapp target snapshot sandbox --json
winapp ui list-windows -a Daylight --on sandbox --json
```

Use actual freshly discovered IDs in place of placeholders, and an absolute host output path:

```powershell
winapp ui screenshot -w --on sandbox -o
winapp ui screenshot -w --on sandbox --json -o
winapp ui screenshot -a --on sandbox --json -o
winapp ui screenshot --help
```

Capture stdout and stderr separately, check exit codes, and verify the actual delivered files and image dimensions. Preserve raw line breaks: the reproduced plain guest path was wrapped across output lines.

For owned-tooltip composition, hover `AddTaskButton` immediately before capture:

```powershell
winapp ui hover AddTaskButton -a --on sandbox
winapp ui screenshot -w --on sandbox --json -o
winapp ui hover AddTaskButton -a --on sandbox
winapp ui screenshot -w --on sandbox --capture-screen --json -o
```

**Independently observed September 18, 2026:**
- Plain screenshot exited 0 and the requested host file existed, but stdout printed a guest `C:\WinApp\artifacts\...` path.
- JSON reported usable requested host paths in **4/4 successful captures**; delivered image dimensions matched JSON.
- Default main-HWND and app-wide screenshots contained labeled composite panels for owned popups, despite help describing separate files.
- Tooltip inclusion reproduced in **2/2 attempts**: separate panel in default composite capture, normal on-screen placement without labeled gutters in `--capture-screen`.
- Successful captures were visually inspected, not just checked for file existence.

Limitations: initial nominally clean captures still contained a small Ctrl+N popup, so they are not a tooltip-free baseline. A separate erroneous output-path invocation was excluded from product findings. No paired local-UI comparison or rerun on the original report's `0.6.3-prerelease.52` was performed. Current `.81` results do not prove whether the older build was fixed or unchanged.

### Expected behavior

- Successful plain output names the **usable host destination** of the delivered screenshot, as JSON already does. Guest staging paths may be diagnostic metadata, not the sole reported artifact location.
- Preserve behavior and path correctness for both JSON and plain output, including long paths, spaces, and terminal line wrapping. Investigate where path translation occurs relative to rendering/wrapping; the root cause is not yet established.
- Preserve transfer/publication ordering and failure behavior: do not print success before the host artifact is delivered, and do not erase recovery evidence after failed publication.
- Correct help and directly affected canonical docs/skills to describe the existing single-image composite behavior for default capture, explicit-main HWND versus app targeting, and the relevant `--capture-screen` distinction. Verify those descriptions against actual code rather than extrapolating from one tooltip.
- Add failing regression coverage for plain-output host-path reporting and retain JSON-path/publication-failure coverage. Validate actual output text, not merely that a replacement helper was called.
- Keep owned-window inclusion and all foreground, target-isolation, coordination, and user-interruption safeguards unchanged.

### Screenshots

A contact sheet of the successful captures was visually inspected during reproduction. No image is attached here; the confirmed findings are the structured/plain output discrepancy and help versus observed labeled composite behavior.

### OS Version and details

Windows host and managed Windows Sandbox: native ARM64. Sandbox connected, interactive, and healthy. Installed CLI during this reproduction: `0.6.3-nmetulev-devtools-extraction.81` (the WindowsApps alias had changed from the original report's `.52`; no downgrade was performed).

Existing Daylight was left running on the planner; final neutral hover dismissed the tooltip. No app code changes, saved edits, resets, or sandbox lifecycle changes were made.

Start with the screenshot commands and help output using the reproduction commands in the issue, comparing plain and JSON paths and default versus --capture-screen behavior. Trace the screenshot publication and output-reporting flow, then locate the canonical help/docs and existing JSON or publication-failure coverage. Done means plain output reports the delivered host path, help matches the existing composite behavior, and regression tests verify output text without changing capture safeguards.

Written by the indexing model from the issue text.