[Feat] Qwen Code (qwen) provider adapter

> Follow-up to #349 (Qwen/MiniMax provider roadmap, where @haofeif confirmed both). Opening this as a dedicated tracking issue so the work is visible and nobody duplicates it — **I'm preparing to implement the Qwen Code provider.** I want to spend more time using CAO + Qwen Code first to calibrate it properly, so this is a heads-up ahead of the PR rather than the PR itself.

## Overview

Add a first-class **Qwen Code** provider (`qwen_cli`) so CAO can orchestrate Qwen's terminal coding agent alongside Claude Code, Codex, Antigravity, Kimi, Cursor, etc.

[Qwen Code](https://github.com/QwenLM/qwen-code) (`@qwen-code/qwen-code`, binary `qwen`, verified v0.19.5) is Alibaba's official terminal coding agent — a **Gemini CLI fork**. That makes it a clean fit for CAO's provider model, and the existing `antigravity_cli` provider (also a Gemini-CLI descendant) is a near-1:1 template. It launches an interactive TUI, supports non-interactive mode, `--approval-mode yolo` for unattended tool approval, `--model`, `--append-system-prompt`, `--mcp-config`, and `--allowed-tools`.

## User Stories

- As a provider experimenter (from #349), I want a Qwen CLI provider adapter, so CAO can orchestrate the Qwen model/provider ecosystem.
- As a supervisor, I want to launch Qwen workers by `--provider qwen_cli` and delegate tasks to them like any other provider (assign / handoff / send_message).

## Acceptance Criteria

- `QWEN_CLI` `ProviderType` + `QwenCliProvider` with `get_status()` **calibrated against real `qwen` TUI output** (idle / processing / completed / error), modeled on the footer-anchored approach in `antigravity_cli` / `cursor_cli`.
- Wired into `manager.py`, `cli/commands/launch.py` (incl. `PROVIDERS_REQUIRING_WORKSPACE_ACCESS`), and the web UI provider list.
- `docs/qwen-cli.md` + README provider table entry.
- Unit tests with captured-output fixtures (`test/providers/fixtures/qwen_cli_*.txt`) and e2e coverage behind a `require_qwen()` skip (assign / handoff / send_message / supervisor), matching how Kimi (#113) and Cursor (#296) landed.

## Proposed solution

Follow the standard provider pattern:

- **Launch:** `qwen --approval-mode yolo [--model ""] [--append-system-prompt ""] [--mcp-config '']` → interactive TUI in tmux, wait for idle, deliver the task via the normal input path.
- **Auth (documented, user-managed like codex/antigravity):** `qwen-oauth` (free tier) or OpenAI-compatible (`--auth-type openai` + `--openai-base-url`, e.g. DashScope/ModelScope).
- **Status detection:** strip escapes, match render-stable footer/structural markers (not spinner words), splitting IDLE vs COMPLETED as `antigravity_cli` does.

## Additional context

**MiniMax (the other half of #349):** while researching, I found MiniMax has **no official interactive coding-agent CLI** — the official `mmx` (`MiniMax-AI/cli`) is a media-generation tool, and the only agentic TUI is an unofficial third-party repo. So rather than a fragile provider, I plan to handle MiniMax as a **documented model** run through providers CAO already has (Claude Code pointed at MiniMax's Anthropic-compatible endpoint, OpenCode, or the new Qwen provider via `--openai-base-url`). @haofeif @plauzy — does that framing work for you, or is there a specific MiniMax CLI you had in mind?

Happy to adjust scope/approach. I'll open the PR once I've validated the status detection against enough real Qwen sessions.