Prompt mode has no non-experimental way to deny a tool: --agent-file tool restriction works but is gated behind KIMI_CODE_EXPERIMENTAL_FLAG=1

Summary

In prompt mode (-p), there is currently no non-experimental way to deny a tool. Tool restriction exists
and works well, but only through --agent-file / --agent, which require
KIMI_CODE_EXPERIMENTAL_FLAG=1. Meanwhile kimi --help lists both flags as ordinary options, so the
requirement is only discoverable at runtime.

Tested with 0.30.0 on Windows.

Why prompt mode has no other lever

-y/--yolo is rejected in prompt mode:

$ kimi -p "…" -y
error: Cannot combine --prompt with --yolo.

which is correct — prompt mode auto-approves regular tool calls implicitly. But that means an automated
caller who wants the agent to read while being unable to write has nothing to reach for, unless the
experimental engine is enabled.

The capability itself works

With KIMI_CODE_EXPERIMENTAL_FLAG=1 and this agent file:

---
name: readonly-reviser
description: Read-only reviser that returns its deliverable on stdout and never writes files
tools:
  - Read
  - Grep
  - Glob
disallowedTools:
  - Write
  - Edit
  - Bash
---
You return your deliverable as your final message on stdout. You never write, create or modify any file.

Write is genuinely refused — the agent was told plainly to create a file and could not, falling back to
suggesting shell commands for a human to run:

$ KIMI_CODE_EXPERIMENTAL_FLAG=1 kimi -p "Create a file named probe-write.txt in the current directory
    containing the single word OK. Do it now." --agent-file ./readonly-reviser.md --output-format text
exit 0
  If you want to create it yourself, any of these work:
  ```bash
  echo OK > probe-write.txt

$ ls
readonly-reviser.md # no probe-write.txt

And reading still works, which is what makes the profile useful rather than merely safe:

$ KIMI_CODE_EXPERIMENTAL_FLAG=1 kimi -p "Read handover-sim.md and reply with ONLY its last non-empty
line, verbatim." --agent-file ./readonly-reviser.md --output-format text
MARKER-LINE-OMEGA

So the enforcement is at the tool boundary, not advisory. That is exactly right.

## Requests

1. **Make tool restriction reachable in prompt mode without the experimental flag** — either by promoting
   `--agent-file`/`--agent` out of the v2 gate, or by adding a direct flag such as
   `--disallow-tools Write,Edit,Bash` (or `--read-only`). Automation that embeds Kimi as a
   reviewer/analyst needs the guarantee to be a supported surface, not an experimental one.
2. **State the requirement in `--help`.** Today both flags appear as ordinary options annotated only
   "(v2 engine only)", and the actual constraint surfaces at runtime:

error: --agent/--agent-file are only available with the v2 engine
(kimi -p with KIMI_CODE_EXPERIMENTAL_FLAG=1).

Naming the env var in the help text would save the discovery round trip.

## Two smaller notes from the same session

- `--agent` and `--agent-file` are mutually exclusive (`error: option '--agent <name>' cannot be used with
option '--agent-file <path>'`). Reasonable, but the help text for `--agent` says custom profiles are
"loaded via `--agent-file`", which reads as though they are meant to be combined.
- The end-of-run hint prints `To resume this session: kimi -r session_…`, but `--help` documents only
`-S, --session`. `-r` does work — it resolves the session and reports `Session "…" not found` for a bad
id — so this is just an undocumented alias in the help output.

## Context

We embed Kimi Code as one lane in a multi-model review pipeline, where the calling engine owns every
durable write and each lane is expected to return its result on stdout without touching the working tree.
A supported read-only guarantee is the difference between enforcing that at the tool boundary and merely
asking for it in the prompt.

Start by tracing prompt-mode option parsing for --agent, --agent-file, --yolo, and the v2-engine error, then inspect how tool restrictions reach the tool boundary. Decide which supported interface is appropriate, document the KIMI_CODE_EXPERIMENTAL_FLAG requirement in --help, and verify that read-only prompt runs still allow reading while refusing writes.