Proposal: add MiniMax Code (MCode) via ACP

[hetaoBackend]

MiniMax Code exposes a native ACP server over stdio through mcode acp. Vibe Kanban already has a reusable ACP harness for Gemini and Qwen, so I propose a first-class MCODE executor that stays entirely on the local product path and does not depend on the sunset remote services. The default permission policy would be supervised. The implementation would cover command construction, availability detection, ACP lifecycle, approvals, cancellation, generated Rust and TypeScript types, the agent selector, and user documentation. It would not write to MCode private state for MCP configuration; any broader client MCP overlay should be handled separately in the shared ACP harness. Before opening a PR, would community maintainers prefer this focused dedicated executor, or should new ACP agents wait for a rewritten version of #3282?

[hetaoBackend]

I prepared a tested implementation branch for concrete review while keeping this Discussion as the upstream gate: hetaoBackend/vibe-kanban@BloopAI:main...hetaoBackend:feat/minimax-code-agent

The branch adds the MCODE executor on the existing ACP harness, supervised permissions by default, approval bridging, generated Rust/TypeScript contracts, UI selection and icons, and setup documentation. Validation completed: 45/45 executor tests, affected public-crate cargo check, clippy -D warnings, generated-types check, web-core TypeScript check, formatting, and a real MCode ACP initialize + session/new smoke. The repository-wide lint reaches the private BloopAI/vibe-kanban-private remote dependency and cannot authenticate, but all public workspace lint before that boundary passes.

I will wait for direction here before opening an upstream PR.