[Bug]: Console project run requires an interactive Sandbox desktop although guest execution is available

### Describe the bug

In an already initialized Windows Sandbox, `winapp run --on sandbox` refuses to launch a console-only program after the interactive session is disconnected, even though `winapp target exec sandbox` still executes console commands successfully.

The program only prints a marker and exits. The refusal cites unavailable real input and screen capture, neither of which it uses.

This is a lower-priority automation workflow issue, not a claim that starting a brand-new sandbox without any user login is supported. **Backlog only for now: the user explicitly requested filing this issue without starting implementation.**

### To Reproduce

Use an already initialized, disposable managed sandbox with a healthy connected baseline. Coordinate exclusive access before deliberately disconnecting its interactive session; do not stop/reset the guest or disconnect the host session.

Create a minimal .NET console project with `OutputType=Exe`, no UI dependencies, and a program that prints a unique marker and exits 0. Run the same project without changing architecture or adding packaging workarounds:

```powershell
winapp --version
winapp target snapshot sandbox --json
winapp run .\ConsoleProbe.csproj --on sandbox
```

Also run a harmless guest console command via the WinApp relay:

```powershell
$script = '[Environment]::OSVersion.VersionString'
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($script))
winapp target exec sandbox -- powershell.exe -NoLogo -NoProfile -NonInteractive -EncodedCommand $encoded
```

Disconnect only the guest's interactive session using supported session controls, preserving the running sandbox, then repeat snapshot, the relay probe, and the exact same project-run command. Reconnect the same guest afterward.

**Independent reproduction on September 18, 2026, using installed CLI `0.6.3-nmetulev-devtools-extraction.81`:**

| Operation | Connected | Disconnected |
|---|---|---|
| Harmless `target exec` console probe | Exit 0 | Exit 0 |
| Same console project via `winapp run --on sandbox` | Marker printed; exit 0 | Build succeeded in 0.72 seconds, then exit 70; marker absent |

The project-run refusal said the disconnected desktop made real input and screen capture unavailable. The existing WinApp execution relay remained usable. This demonstrates a project-runner readiness distinction, not complete transport loss.

**Lifecycle caution from the test:** reconnecting with `wsb connect` while the stale old viewer remained open produced two viewer windows and `sandbox_target_ambiguous`. The user closed the viewer windows; the original guest survived, and a single connection restored the same sandbox epoch with input/capture readiness. Do not blindly repeat reconnect or kill a process tree. This adjacent viewer-recovery concern is not part of the console-readiness fix requested here.

### Expected behavior

For supported console-only project launches in an already initialized guest, require the execution capabilities actually needed by the launch path rather than real-input/screen-capture readiness.

Investigation and acceptance criteria for future work:
- Establish whether the actual console project-launch path works while the interactive session is disconnected before relaxing any readiness check. Do not assume a successful relay command proves every activation path works.
- Distinguish GUI/desktop-dependent launches from genuinely console-only projects using reliable existing project/launch metadata.
- Preserve desktop-readiness requirements and fail-closed behavior for GUI interaction, real input, and screen capture.
- Preserve user identity, package/alias semantics, runtime checks, coordination, and explicit execution-target isolation. Never fall back to host execution or reconnect the viewer silently just to report a console success.
- Add connected/disconnected console regression coverage plus GUI/input/capture refusal coverage. Verify the actual program marker and exit code, not merely successful compilation.
- If a launch mechanism fundamentally requires an active user session, report that execution-specific reason clearly rather than implying all console programs need input or screen capture.
- Consider early readiness validation before expensive builds only where meaningful, while retaining validation at launch to handle state changes.

Scope limitations: this is not a request for headless initialization of a fresh sandbox, unattended GUI automation, blanket removal of desktop checks, or a transport rewrite. The test did not exercise a stopped guest. Windows Sandbox's own `wsb exec --run-as ExistingLogin` has an active-user-session requirement; the successful disconnected probe above used WinApp's already-running relay, not that direct WSB execution path.

### Screenshots

N/A. Evidence consists of console output, marker presence, exit codes, and target-readiness snapshots.

### OS Version and details

Installed CLI during independent reproduction: `0.6.3-nmetulev-devtools-extraction.81`; Windows host and managed Windows Sandbox native ARM64. Existing guest was initialized and connected before testing. Original report used `0.6.3-prerelease.52`; this reproduction establishes the current `.81` behavior without claiming a version-to-version comparison.

After user-assisted viewer cleanup, the same guest was reconnected successfully; no guest stop/reset or application-data edits were performed. The disposable console fixture deployment was retained for evidence.

Start by reproducing the connected and disconnected cases with `winapp run`, `target exec`, and `target snapshot --json` on an already initialized sandbox. Trace the project-launch readiness path and compare it with the relay path; done means console launches verify the marker and exit code while GUI, input, and capture requirements remain enforced with regression coverage.

Written by the indexing model from the issue text.