[feat] opencode_cli: `cao launch --yolo` is a no-op (upstream TUI lacks a skip-permissions flag)

## Summary

`cao launch --yolo` is silently ignored on `opencode_cli`. Unlike other providers (`claude_code` → `--dangerously-skip-permissions`, `codex`/`gemini_cli`/`kimi_cli` → `--yolo`, `copilot_cli` → `--allow-all`, `kiro_cli` → `--trust-all-tools --legacy-ui`), the opencode_cli provider has no runtime flag to translate `allowed_tools=['*']` into.

Permission enforcement on `opencode_cli` is **install-time only** — `cao_tools_to_opencode_permission` writes the `permission:` block into the agent's frontmatter at `cao install` time. `cao launch --yolo` cannot loosen an already-installed profile.

## Root cause — upstream limitation

OpenCode's CLI splits permission handling by command:

| opencode command | `--dangerously-skip-permissions`? |
|---|---|
| `opencode` (TUI — what CAO drives) | ❌ not supported |
| `opencode run` (headless one-shot) | ✅ supported (undocumented easter egg) |

CAO drives opencode in TUI mode (`opencode --agent ` inside tmux) because that's what provides the interactive lifecycle + status detection CAO needs. The TUI does not accept the flag.

Tracked upstream:
- sst/opencode#8463 — *Add `--dangerously-skip-permissions` (YOLO mode)* — **open**
- sst/opencode#11831 — *YOLO Mode — Auto-Approve All Permission Prompts* — **open**
- sst/opencode#9070 — *YOLO Mode - Skip Permission Prompts* — **open**
- sst/opencode#18482 — *Add `--yolo` unrestricted execution mode for OpenCode* — **open**
- sst/opencode#23370 — *The `--dangerously-skip-permissions` flag ought be documented* — **open** (even the existing `run`-only flag is undocumented)

## Current CAO behaviour

`src/cli_agent_orchestrator/providers/opencode_cli.py` stores `allowed_tools` via `super().__init__(...)` but `_build_launch_command()` never consults it. From the docstring at `opencode_cli.py:92`:

> `allowed_tools: Optional CAO tool list (informational; enforcement is via frontmatter)`

So:
- `cao install ... --provider opencode_cli` → writes `permission:` block from `allowedTools` (or `*` if profile has `allowedTools: ['*']`)
- `cao launch --yolo` on opencode_cli → no change to runtime behaviour; permissions from the installed frontmatter still apply

## User impact

A user running `cao launch --agents my_agent --provider opencode_cli --yolo` expecting unrestricted tool access will instead get whatever permissions were baked in at install time. Silent no-op — no warning, no error. Inconsistent with every other provider.

## Proposed options

### Option 1 — Document + warn (low-risk, ship now)
- Note in `docs/opencode-cli.md` that `--yolo` does not apply at runtime on opencode_cli; users must install the profile with `allowedTools: ['*']` to get yolo behaviour.
- In `src/cli_agent_orchestrator/cli/commands/launch.py`, when `yolo and provider == "opencode_cli"`, print a warning: *"--yolo is a no-op on opencode_cli. Permissions are set at install time. Re-run `cao install` with a profile containing `allowedTools: ['*']` for unrestricted access."*

### Option 2 — Temp agent workaround (medium-risk)
- When `yolo` is set, write a temp opencode agent `.md` to `$OPENCODE_CONFIG_DIR/agent/-yolo.md` with `permission: { "*": "allow" }` and `tools: { ... all true }`, then launch with `--agent -yolo`.
- Clean up on terminal close.
- Adds file churn in the user's opencode config dir and diverges from the installed profile identity.

### Option 3 — Wait for upstream
- Track sst/opencode#8463. When a `--dangerously-skip-permissions` or `--yolo` flag lands for the TUI and ships in a stable opencode release, add it to `_build_launch_command()` behind a `"*" in self._allowed_tools` check. ~5 lines.

## Recommendation

Ship **Option 1** now (matches the *experimental — single-agent only* scoping), then adopt **Option 3** once upstream ships a TUI-compatible flag. Avoid Option 2 unless a concrete customer needs runtime-toggleable yolo on opencode before upstream resolves it.

## Related

- PR #193 (opencode_cli provider integration)
- PR #201 / #202 (kiro_cli `--yolo` + `--model` fix — same shape of problem, resolved at the provider level because kiro-cli exposes the flag)

Read src/cli_agent_orchestrator/cli/commands/launch.py and docs/opencode-cli.md, starting at the opencode_cli launch handling and the existing --yolo documentation. Done means warning users that runtime --yolo is ignored and documenting that unrestricted permissions require installation with allowedTools: ['*']; upstream flag support is out of scope.

Written by the indexing model from the issue text.