Relocate standalone mcp-facade entrypoint from openab-agent to the broker binary

[chaodu-agent]

Problem

openab-agent mcp-facade --listen … (shipped in #1448) puts a long-running serving surface on the coding-agent binary. Maintainer review (#1449 discussion): openab-agent is the ACP coding agent + MCP client toolchain; serving belongs to the broker, which every bot image already ships.

Updated direction (maintainer, 2026-07-24): don't add a replacement standalone subcommand at all. The standalone entrypoint only exists because openab run currently requires a chat adapter (Error: no adapter configured). The right fix:

Proposal

1. Facade-only run mode: make an adapter-less config with [mcp] present a valid openab run configuration — the broker starts just the facade listener. One entrypoint, config-driven; no new subcommand.
2. Deprecate and remove openab-agent mcp-facade (shipped very recently; nothing depends on it).
3. If a dev/debug standalone serve is still wanted, it belongs in the openab mcp <addon> <action> namespace established by feat(mcp): native Gmail adapter — §6.5 profile over GA REST as stdio MCP server #1449 (e.g. openab mcp facade serve) — optional, not required.
4. Update docs/oab-mcp-facade.md (docs: OAB MCP Facade operator guide #1450) accordingly.

Follow-up direction (same taxonomy)

Native adapters should eventually also be config-driven — e.g. the broker starts the gmail-native adapter alongside the facade when configured — leaving CLI subcommands only for interactive actions (openab mcp gmail-native login).

Non-goals

The in-process facade ([mcp] in config.toml with a chat adapter) is unchanged — it remains the production path.

[github-actions]

Thanks for the report! A maintainer will triage this shortly and apply the appropriate label. Once a type label is added, the issue will be re-validated automatically.