winapp run: suggest --debug-output when an attached app exits with a nonzero code

## Problem

The existing `winapp run --debug-output` already provides the diagnostics needed to diagnose the startup failure below. This request is only to make that option discoverable from a plain attached `winapp run` when the app exits with a nonzero code.

The CLI correctly propagates the app's exit status, but its last console message says the app launched successfully, with no suggestion to rerun using `--debug-output`. The deliberately invalid package-dependent API call below is just a reproducible crash trigger, not a WinApp runtime bug.

## Minimal reproduction

Tested with the installed WinUI template pack **`0.0.6-alpha`**:

```powershell
winapp new --template winui --template-version installed --name StartupCrashRepro --use-defaults
cd StartupCrashRepro
```

1. Add this property to `StartupCrashRepro.csproj`, retaining `Package.appxmanifest`:

```xml

None

```

2. Add this as the first statement in `App.xaml.cs` → `App.OnLaunched`:

```csharp
_ = Windows.Storage.ApplicationData.Current.LocalFolder.Path;
```

`Windows.Storage.ApplicationData.Current` requires package identity, so this intentionally fails when unpackaged. The app exception is expected; the missing terminal CLI diagnostic is the issue.

3. Run attached on the local machine, without debug capture:

```powershell
winapp run .\StartupCrashRepro.csproj --arch arm64 --on local
$LASTEXITCODE
```

`arm64` is the tested architecture. No `--detach` or readiness timeout is involved.

## Actual result

Reproduced twice with the same source:

| Run | App PID | Native app exit | CLI exit | stderr |
|---|---:|---|---:|---|
| Plain #1 | 28552 | `0xC000027B` | `-1073741189` | Empty |
| Plain #2 | 82960 | `0xC000027B` | `-1073741189` | Empty |

Both runs ended their CLI output with the equivalent of:

```text
Preparing Windows App Runtime...
✅ Windows App Runtime ready
✅ Launched StartupCrashRepro (PID: 28552)
```

Nothing followed to report the app's abnormal exit or recommend diagnostic capture. **The nonzero exit status was correctly propagated.** Native `GetPackageFullName` checks returned `15700` (`APPMODEL_ERROR_NO_PACKAGE`) for the launched processes, confirming these were genuinely unpackaged runs.

## Requested change: a hint in `winapp run` only

When an attached app exits with a nonzero code and `--debug-output` is not enabled, print a short suggestion in the normal human-readable output:

```text
App exited with code 0xC000027B. Rerun with --debug-output for exception details.
```

The wording is illustrative. The change is limited to this hint:

- Preserve the existing exit-code propagation and machine-readable output contract.
- Do not print the rerun hint when `--debug-output` is already enabled or the app exits successfully.
- Do not enable debug capture automatically or add new crash analysis, dump collection, or startup-readiness checks.
- No `BuildAndRun.ps1` or Sandbox changes are requested.

The existing `--debug-output` implementation is sufficient; this is a discoverability improvement in `winapp run` only.

## Diagnostic control / current workaround

Run the **unchanged** project with:

```powershell
winapp run .\StartupCrashRepro.csproj --arch arm64 --on local --debug-output
```

This correctly identified the failing call:

```text
Exception: System.InvalidOperationException
Message: Operation is not valid due to the current state of the object.
...
StartupCrashRepro.App.OnLaunched in App.xaml.cs:41
```

The debug log contained `HResult: 0x80073D54` (no package identity). This confirms the underlying app error is diagnosable using existing tooling; the plain attached run does not surface that next step.

## Tested environment

- WinApp CLI: **`0.6.3-nmetulev-devtools-extraction.81`** — prerelease/development build; **stable release untested**
- Windows 11 Enterprise 26H1, build **28000.2956**, ARM64
- .NET SDK **10.0.400**
- WinUI template pack **`0.0.6-alpha`**
- Windows App SDK **2.5.1**
- Target framework: `net10.0-windows10.0.26100.0`
- Execution target: **local only**

## Related scope

- Distinct from microsoft/winappCli#836: debug capture identified the correct call here; no incorrect first-chance crash context was observed.
- Distinct from microsoft/winappCli#818: this is reporting an already-observed fatal exit in an attached run, not adding startup-readiness verification or a survival window.

Start at the `winapp run` command handling and inspect the existing `--debug-output` and attached-process exit reporting paths. Ensure a nonzero app exit without debug output produces the requested rerun hint, while successful exits, debug-enabled runs, and machine-readable output remain unchanged; run the reproduction commands to verify the behavior.

Written by the indexing model from the issue text.