Make MCP channel push (Discord-style bridges) usable outside the experimental v2 engine

What feature would you like to see?

Kimi Code's agent-core-v2 already has a generic MCP "channel push" mechanism: an MCP server can send a notifications/kimi/channel notification to wake a running session immediately, instead of the agent having to poll a tool. This is exactly what a chat-bridge plugin (e.g. a Discord DM bridge) needs — without it, the only option is polling, which means missed messages until the agent happens to check.

Right now this only works if the whole interactive CLI is switched onto the experimental agent-core-v2 engine (the KIMI_CODE_EXPERIMENTAL_FLAG master switch), not just the dedicated mcp-channel flag. Since the default kimi CLI still runs on the v1 engine, the push mechanism is effectively unreachable for normal users, and until recently a pushed message also had no dedicated rendering in the TUI (it only showed up indirectly, through the model's own paraphrase of what it received).

We'd like this to become a real, supported capability:

• MCP channel push reachable without requiring the full experimental-v2 engine switch (or a documented path to enable it that plugin authors can rely on).
• The pushed message rendered distinctly in the TUI (sender/server + the actual text), not just inferred from the model's response.

This would let third-party MCP plugins (chat bridges, notification relays, etc.) wake a running session reliably and show up cleanly in the transcript.

Additional information

We already have a working implementation for the TUI-rendering half (wiring the existing mcp.channel.received event through to a rendered transcript entry, mirroring the existing cron.fired handling) and have tested it end-to-end against a Discord MCP bridge plugin. Happy to open a PR once there's agreement on direction — in particular whether push should be decoupled from the full experimental-v2 switch, or whether the plan is for v2 to become the default engine on its own timeline.

Review the default v1 CLI path, the experimental-v2 and mcp-channel flags, and the existing mcp.channel.received/cron.fired TUI event flow. Done means plugin authors have a supported way to enable channel push without the full v2 switch, and pushed notifications appear as distinct transcript entries with sender/server and text; validate against the Discord MCP bridge.