ACP reports default mode while the engine uses auto or yolo permissions

What version of Kimi Code is running?

Current main at 911d41b0f6aa83ef08b2ee5fe8d055218c0951b2.

Which open platform/subscription were you using?

Not provider-specific.

Which model were you using?

Not model-specific.

What platform is your computer?

All platforms; this is in the native ACP session state projection.

What issue are you seeing?

The native ACP server reports every newly activated session as default mode even when the engine is actually running with auto or yolo permissions.

AcpSession initializes currentModeId to default. During init(), it restores the model and thinking level from the engine, but it never reads the current permission or plan state. As a result, both of these response fields can disagree with the mode that governs tool execution:

• modes.currentModeId
• the mode config option's currentValue

This is especially misleading for permission-sensitive IDE UI: the client can display the Default/manual-approval mode while tool calls are actually being auto-approved by the engine.

What steps can reproduce the bug?

1. Set the following in ~/.kimi-code/config.toml:

   default_permission_mode = "yolo"
   

2. Start kimi acp and send initialize followed by session/new.

3. Inspect the session/new result.

4. Observe that modes.currentModeId and the mode config option both report default.

5. The main agent is nevertheless using the configured yolo permission mode.

The same mismatch occurs when loading or resuming a session whose persisted permission mode is auto or yolo.

What is the expected behavior?

ACP should derive the initial mode from the live engine state before returning from session/new, session/load, or session/resume:

• active plan state → plan
• manual permission state → default
• auto permission state → auto
• yolo permission state → yolo

The first-class modes state and the mode config option should always agree.

Additional information

The Klient agent facade currently exposes setPermission() and getPlan(), but not a permission getter. A focused fix could expose the current permission mode through the existing engine service/facade boundary, then seed AcpSession.currentModeId together with the other engine-backed state during init().

Start with AcpSession.init() and trace how session/new, session/load, and session/resume seed engine-backed state. Inspect the Klient facade's setPermission() and getPlan() boundary to determine where the current permission mode can be read. Done means modes.currentModeId and the mode config option reflect plan, default, auto, or yolo consistently.