[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",
]
```

Start with src/qwenpaw/cli/tui/transport/acp.py and inspect how the ACP backend command is assembled from sys.executable. Compare the command needed by the packaged qwenpaw.exe with the normal Python invocation, then run qwenpaw tui on Windows. Done means the packaged Desktop TUI starts its ACP backend and creates or resumes a usable session without showing transport: Connection closed.

Rédigé par le modèle d'indexation à partir du texte de l'issue.