[Feat] Cross-VPS CAO fleet coordinator, one-command node bootstrap, and Qwen/MiniMax provider roadmap

## Overview

First of all: huge thanks to the maintainers. After spending a full day using CAO, I think this project is genuinely brilliant. The supervisor/worker model, tmux isolation, MCP primitives, Web UI, MCP Apps, and `cao-ops-mcp` / `cao-mcp-server` surfaces make CAO feel like a very natural foundation for a larger AI operations layer.

I would like to discuss a possible next direction: a cross-host CAO fleet coordinator.

My personal use case is that I have multiple VPS machines. Ideally, each VPS could run its own CAO node, while one AI coordinator/operator can observe and manage the whole fleet: node health, installed providers, active sessions, worker placement, logs/events, and task delegation across machines.

This would extend CAO from “one machine coordinating many agents” to “one coordinator managing many CAO nodes,” while keeping the current localhost-first behavior unchanged. And so far, i've verified this case, it works using only a panel to management all of my vps' agents.

## User Stories

- As an operator with multiple VPS machines, I want one CAO coordinator to see all nodes, so I do not need to SSH into every host manually.
- As an AI supervisor, I want to launch workers on a selected remote node, so tasks can be distributed by provider availability, capacity, region, or cost.
- As a new user, I want a one-command bootstrap/install flow for a fresh VPS, so adding a machine to the fleet is simple.
- As a provider experimenter, I want Qwen CLI and MiniMax CLI provider adapters, so CAO can orchestrate more model/provider ecosystems.
- As a security-conscious user, I want remote control to be explicit and authenticated, ideally easy to run behind SSH, WireGuard, or Tailscale.

## Proposed solution

I imagine this as a phased implementation:

1. Add a one-command VPS bootstrap flow for installing `tmux`, `uv`, CAO, and optional service units.
2. Add a lightweight remote node registry on the coordinator side.
3. Let each node expose health/capability/session snapshots through the existing HTTP API or MCP management boundary.
4. Extend the Web UI / MCP Apps fleet view to show sessions grouped by node.
5. Add node-aware launch and routing options, such as selecting a node by provider, label, region, or capacity.
6. Track Qwen CLI and MiniMax CLI as additional provider adapters following the existing provider patterns.

So far i've tried to make a tailnet to make all my vps in the same tailscale env, using cao-mcp-server to manage every vps' agent, and it performed pretty much good. Any suggestion are very welcome, if there's mistake please let me know. Thanks again and really appreciate it.

No specific file or test is named. Start by reviewing the existing HTTP API or MCP management boundary, then inspect the Web UI/MCP Apps surfaces and existing provider patterns mentioned in the issue. A complete result would need a defined phase and acceptance criteria for fleet registration, node visibility, remote launch, bootstrap, or provider support.

Written by the indexing model from the issue text.