[Bug]: Windows Desktop TUI fails with `transport: Connection closed` because packaged qwenpaw.exe rejects `-m qwenpaw acp`

## QwenPaw Version

2.1.0

## Description

The QwenPaw Desktop TUI on Windows fails to start a session. The Textual UI opens, but the status changes to `error` and the transcript shows:

```text
transport: Connection closed
```

The expected behaviour is that `qwenpaw tui` starts its local ACP backend and opens a usable chat session.

I traced the failure to the TUI backend launch command. The TUI currently tries to start the ACP backend with Python-style module invocation:

```cmd
qwenpaw.exe -m qwenpaw acp --local-diagnostics
```

However, the Desktop-packaged `qwenpaw.exe` does not support `-m`:

```text
Usage: qwenpaw [OPTIONS] [COMMAND] [ARGS]...
Try 'qwenpaw --help' for help.

Error: No such option '-m'.
```

Because the ACP child process exits immediately, the TUI reports `transport: Connection closed`.

**Related PR(s):** N/A

**Security considerations:** No credentials, API keys, or private config values are included in this report.

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [x] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Environment

- **QwenPaw version:** 2.1.0
- **OS:** Windows 10 AMD64
- **Install method:** QwenPaw Desktop packaged app
- **Python version (if applicable):** bundled Desktop runtime (Python 3.11.x)

## Steps to Reproduce

1. Install/run QwenPaw Desktop 2.1.0 on Windows.
2. Open Windows PowerShell or Windows Terminal.
3. Run:

```cmd
qwenpaw tui
```

4. Wait for the TUI to initialise.

## Actual vs Expected

- **Actual:** The TUI opens, shows `error`, then displays `transport: Connection closed`; no session is created.
- **Expected:** The TUI starts `qwenpaw acp` successfully and creates/resumes a session.

## Logs / Screenshots

Direct reproduction of the packaged executable rejecting the TUI's backend command:

```cmd
qwenpaw -m qwenpaw acp --help
```

Output:

```text
Usage: qwenpaw [OPTIONS] [COMMAND] [ARGS]...
Try 'qwenpaw --help' for help.

Error: No such option '-m'.
```

TUI error shown in the interface:

```text
transport: Connection closed
```

Relevant source path:

```text
src/qwenpaw/cli/tui/transport/acp.py
```

The transport currently builds the backend command from `sys.executable` like this:

```python
[
sys.executable,
"-m",
"qwenpaw",
"acp",
"--local-diagnostics",
]
```

In the Desktop build, `sys.executable` is the packaged `qwenpaw.exe`, so this becomes the invalid command:

```cmd
qwenpaw.exe -m qwenpaw acp --local-diagnostics
```

## Additional Notes

The Desktop backend itself is healthy: `qwenpaw doctor` passes, the API health endpoint returns HTTP 200, and the configured model works in the Console.

A local workaround is to install `qwenpaw==2.1.0` in a normal Python 3.11 virtual environment and run:

```cmd
python -m qwenpaw tui
```

That works because `python.exe` supports `-m qwenpaw`.

Suggested fix: when running under a packaged/frozen `qwenpaw.exe`, spawn the ACP backend as:

```cmd
qwenpaw.exe acp --local-diagnostics
```

instead of:

```cmd
qwenpaw.exe -m qwenpaw acp --local-diagnostics
```

For example, the TUI transport could detect frozen/Desktop builds and use:

```python
[
sys.executable,
"acp",
"--local-diagnostics",
]
```