[Bug] deny wildcard "*" overrides preceding allow rules in --prompt mode

Summary

According to the Configuration files docs, permission rules are "matched in order — the first matching rule takes effect."

However, in kimi --prompt (headless) mode, a catch-all deny rule with pattern "*" placed after explicit allow rules appears to override the earlier allow rules, causing allowed tools to be rejected.

Reproduction

Create an ephemeral KIMI_CODE_HOME with this config.toml:

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Read"

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Grep"

[[permission.rules]]
decision = "allow"
scope = "user"
pattern = "Glob"

[[permission.rules]]
decision = "deny"
scope = "user"
pattern = "*"

Run:

export KIMI_CODE_HOME=/path/to/that/home
kimi --prompt "Read README.md and summarize it in one sentence." --output-format text

Expected behavior

Read should be permitted because the first matching rule is allow Read.

Actual behavior

Read is denied with reason "Blocked by the read-only consultation wrapper" (the deny * rule).

Additional observations

• Configuring only allow Read works.
• Configuring allow Read followed by deny Bash works and correctly blocks only Bash.
• Configuring allow Read/Grep/Glob followed by deny "*" blocks Read.

Environment

• Kimi Code CLI version: 0.27.0
• OS: macOS
• Shell: bash

Impact

This makes the documented "allow specific tools, then deny all" pattern unusable for headless wrappers that want to restrict Kimi to a read-only toolset.

Reproduce the issue with an ephemeral KIMI_CODE_HOME and the config.toml rules shown, then trace permission evaluation in --prompt mode, focusing on rule ordering and the catch-all deny pattern. Done means earlier allow rules for Read, Grep, and Glob remain effective while the later deny "*" still blocks other tools; verify the documented reproduction and related allow/deny cases.