[Bug]: Sandbox error windows are counted as usable viewers, causing false ownership ambiguity

### Describe the bug

WinApp counts a Windows Sandbox error-only window as a usable remote-session viewer. When one real viewer and one terminal-error window exist, the CLI reports `sandbox_target_ambiguous` even though only one guest is running and only one window renders that guest. Characterization tests also show that an error-only window by itself can be accepted as a rendered client.

This prevents reliable readiness reporting and blocks workflows. The user observed the failure twice in one day.

**Keep two questions separate:**
- Confirmed CLI defect: invalid/error-only viewer participates in client ownership/readiness selection.
- Trigger under investigation: what launches the extra error window. For the currently observed dialog, the viewer process argv contains `--help` and no sandbox ID. The originating caller, and whether it invoked the viewer directly or through a wrapper, remain unconfirmed. There is no evidence that WinApp's normal StartAsync path created this particular dialog or that two guest VMs were running.

### To Reproduce

Observed on September 18, 2026 with installed CLI `0.6.3-nmetulev-devtools-extraction.81`:

1. A managed guest is running with a legitimate connected viewer.
2. An additional `WindowsSandboxRemoteSession.exe` window shows a terminal error. The user's screenshot reads: **"Only one running instance of Windows Sandbox is allowed."**
3. Run read-only checks:

```powershell
wsb list --raw
winapp target snapshot sandbox --json
```

Observed:
- `wsb list --raw` lists exactly **one** running guest.
- One viewer contains the actual remote-desktop rendering/input controls and was launched with that guest's `--id`.
- The other window contains only the singleton error message and Close button.
- Snapshot reports `sandbox_target_ambiguous` and effective input/capture readiness false.

**Current error-window process evidence:** Windows Sandbox RemoteSession package version `0.8.107.0`, native ARM64; created at 15:49:08.560 PDT. Its command was `WindowsSandboxRemoteSession.exe --help`, with no `--id` or guest GUID. The parent process had already exited; bounded audit and parent/repro-session evidence did not identify the caller. Do not execute that help probe merely to reproduce the issue on a shared machine: it has demonstrated launch side effects.

**Related earlier observation:** disconnect/reconnect left a stale error viewer saying "The remote environment is logging off. The connection will be closed." alongside a functioning viewer, also causing ambiguity. User-assisted closing of viewer windows preserved the same guest; one subsequent connection restored readiness. This does not establish a universally safe programmatic Close/kill contract.

**Source/test confirmation:** investigation of `WindowsSandboxWindowController` on main revision `09a401bc9877625a1e7b2b915fea09833bafbb05` found that matching process windows are not distinguished by terminal-error versus remote-session state. Three isolated characterization tests plus 68 related lifecycle/controller/lock tests passed, confirming current behavior: sole error identity is accepted, real renderer plus error is ambiguous. No production changes or destructive live repro were made. Exact installed `.81` source revision has not been independently established.

### Expected behavior

- Exclude only viewers **positively identified as terminal-error/non-session windows** from usable-client selection and rendered/readiness reporting.
- A real viewer plus a conclusively identified failed viewer should not cause false ambiguity.
- A sole error window should not imply a rendered interactive desktop.
- A remembered viewer that has become an error-only window must not remain accepted merely because its PID/HWND still match.
- Preserve existing target identity, epoch, PID/HWND/start-time validation and fail-closed behavior for genuinely ambiguous cases.
- Starting, unknown, inaccessible, or temporarily nonrendering windows must not simply be ignored. A renderer plus an unknown window remains conservative; two genuine viewers retain the established ownership/ambiguity policy.
- Establish a stable, bounded, nonlocalized classification signal before implementing a filter. **English error-text matching alone is not an acceptable production classifier.** Do not replace one guess with another.
- Detection should be inspect-only: no closing viewers, reconnecting, deleting ownership state, stopping/resetting guests, or weakening validation to recover automatically.
- Add failing regressions for the confirmed cases and unknown/starting/inaccessible/stale-identity safety cases, then verify the candidate against retained live evidence where safe.

Also continue the bounded trigger investigation: identify which command/tool invokes the viewer in the unexpected mode, or document why attribution remains unknown. Distinguish direct viewer help probes, legacy sandbox launches, normal `wsb start`/`connect`, and concurrent CLI preparation. Do not assign blame based on timing alone.

A separate test demonstrated that packaged/unpackaged state roots have independent mutation locks and may adopt the same mocked guest with different epochs. That test's StartCount stayed **zero**, and actual cross-root invalidation was not demonstrated. Do not bundle state migration, global locking, epoch shims, or ownership-store redesign into this fix without independent causal evidence and a scope decision.

### Screenshots

The user supplied a screenshot of a Windows Sandbox Error dialog displaying:

> Only one running instance of Windows Sandbox is allowed.

Read-only accessibility inspection confirmed the same text while an independent `wsb list` showed only one guest and a separate viewer had remote-desktop controls.

### OS Version and details

Windows host and guest native ARM64. Installed WinApp CLI observed: `0.6.3-nmetulev-devtools-extraction.81`. Windows Sandbox package version `0.8.107.0`. The same guest and ownership epoch persisted through the investigation.

This is a shared development machine with concurrent agent sessions. No guest stop/reset, process kill, state copying, credential disclosure, viewer dismissal, or production edits were performed in the read-only ownership investigation.

Start with WindowsSandboxWindowController and the three isolated characterization tests described in the issue. Run those tests and the 68 related lifecycle, controller, and lock tests before investigating a bounded, nonlocalized signal for terminal-error windows. Done means regressions cover error-only, unknown, starting, inaccessible, stale-identity, and genuine-viewer cases without weakening existing validation.

Written by the indexing model from the issue text.