Expose /goal (autonomous goal mode) over the ACP adapter

What feature would you like to see?

Add first-class support for Kimi Code's /goal autonomous goal mode to the ACP adapter so that ACP clients (Zed, JetBrains AI Chat, etc.) can create, inspect, pause, resume, replace, queue, and cancel goals, instead of forcing users to drop back to the TUI.

Today the /goal slash command exists in the TUI (Goals guide) and is documented as a persistent objective that Kimi Code works toward across automatically continuing turns, with lifecycle commands such as /goal status, /goal pause, /goal resume, /goal cancel, /goal replace <objective>, and /goal next <objective>. The same docs page explicitly notes that in non-interactive prompt mode only goal creation is supported, and that /goal next and the other management commands are TUI controls and are not handled by kimi -p.

The ACP capability matrix (kimi acp subcommand reference) confirms this gap on the agent side: the documented stable ACP surface (initialize, authenticate, session/new, session/load, session/resume, session/prompt, session/cancel, session/list, session/set_mode, session/set_config_option) has no method for starting or managing a goal, and session/close / session/logout are not implemented either. As a result, when running Kimi Code through an ACP client:

• There is no way to enter goal mode at all, because /goal is a TUI slash command and not exposed via session/prompt.
• There is no way to queue the next goal with /goal next <objective>, even though the TUI supports it and it would map naturally to available_commands_update or a dedicated session/goal extension.
• There is no way to inspect, pause, resume, or cancel a goal from inside the IDE; ACP clients only see session/cancel for the current turn, which interrupts a turn rather than pausing the goal lifecycle.
• The /goal status, pause, resume, cancel, and replace subcommands, which the Slash Commands reference marks as "always available" or "idle only", are completely unreachable from the ACP channel.

The expected behavior is that an ACP client should be able to:

1. Start a goal as part of session/new or via a prompt turn, e.g. by sending /goal <objective> (and /goal next <objective> for queuing) as the first user content block so the adapter routes it to the goal subsystem instead of the normal prompt flow.
2. Receive goal lifecycle updates on the existing session/update stream, alongside the current agent_message_chunk, tool_call*, plan, config_option_update, and available_commands_update notifications. The available_commands_update payload should reflect the new /goal pause, /goal resume, /goal cancel, and /goal replace commands when a goal is active.
3. Pause, resume, cancel, or replace a goal through dedicated ACP methods, or, at minimum, by accepting the corresponding /goal <subcommand> slash commands as content blocks in session/prompt. The current turn-cancel surface (session/cancel) is not an adequate substitute, because it cannot distinguish "interrupt the current turn" from "pause the goal for later resumption".
4. Advertise the new capability in the agentCapabilities field of the initialize response (for example, goalCapabilities.create, goalCapabilities.manage, goalCapabilities.queue) so ACP clients can enable a goal-mode toggle in their UI, mirroring how the existing sessionCapabilities.list and promptCapabilities.embeddedContext flags already drive IDE UI.

Additional information

Related existing issues for context: #226 and #301 requested /goal itself for Kimi Code (later shipped in the TUI), and #716, #1329, #1821, and #1977 track follow-up work on goal mode. None of them covers ACP exposure, which is what this issue is about.

Reproducible today:

1. Start Kimi Code as an ACP server: kimi acp.
2. Connect from an ACP-compatible IDE such as Zed or JetBrains AI Chat.
3. Try to launch a long-running autonomous task equivalent to /goal Fix every failing checkout test and run the checkout test suite successfully. from the IDE. There is no command palette entry, no slash command, and no protocol method to do so; the user has to start a separate TUI session, run /goal there, and then babysit the IDE session that is no longer the source of truth for the goal.

This breaks the "drive Kimi Code entirely from the IDE" workflow that kimi acp is otherwise designed to provide.

Start with the kimi acp entry point and trace the existing session/prompt, session/update, available_commands_update, and initialize agentCapabilities flows. Define how goal creation and lifecycle management map to those ACP surfaces, then verify that an ACP client can create, inspect, pause, resume, replace, queue, and cancel goals with capability advertisements.