[Feature]: 支持自定义 auto 模式的权限判定 prompt 与判定模型 #549

当前这两项都无法做到，原因如下。

### 问题 1：beta.promptOverride 配置项存在，但不产生任何实际效果

MiniMax Code 提供了 beta.promptOverride 开关与 <dataDir>/internal/prompts/llm-gate-classifier.md
覆盖路径，配置确实会被读取：

// packages/local-runtime/.../permission-service.ts
function resolvePermissionPrompt(config, name) {
    if (config.beta?.promptOverride) {
        const override = readOptionalPrompt(path.join(config.dataDir, 'internal', 'prompts',
`${name}.md`));
        if (override) return override;
    }
    ...
}

但该 prompt 从不会被发送给云端判定服务。auto 模式的 LLM 判定通过 POST
/mavis/api/v1/permission/check 完成，请求体中不包含 prompt 内容，只有：

tool_name, input, platform, home_dir, workspace_root, mode,
conversation_context?, agent_id?, session_id?, daemon_prompt_version?

实际使用的 prompt 由云端服务持有。本地这份文件只是副本。

同一份代码中的官方注释也确认了这一点：

│ Prompt provider — the cloud side owns the llm-gate-classifier prompt, but this hook still serves
│ tooling/tests that import the prompt text directly.

即 resolvePrompt 仅用于工具链和测试直接读取 prompt 文本，本身不参与真实判定流程。结果是：用户按官
方方式配置了覆盖文件，却观察不到任何行为变化，且没有任何提示说明该配置无效。

### 问题 2：defaultLightModel 配置被无条件覆盖，无法指定判定模型

config.yaml 中存在 defaultLightModel 配置项，但在配置归一化时被强制覆盖：

// packages/local-runtime/.../config.ts
function toRuntimeConfig(local) {
    return {
        ...
        defaultModel: local.defaultModel,
        defaultLightModel: local.defaultModel,   // ← 无条件覆盖用户配置
        ...
    };
}

即便用户在 config.yaml 中显式写入 defaultLightModel: <某个轻量模型>，运行时仍会将其替换为
defaultModel。而分类器正是通过 H4t() 读取 defaultLightModel ?? defaultModel 来确定判定模型的。

结果是：权限分类器被迫使用与主会话相同的模型。对于一个短输入、短输出、只需返回 allow/confirm/block
 的判定任务，使用 512K 上下文的主模型既慢又贵，而且无法独立调优——用户想给分类器换个更便宜、更快的
模型都做不到。

### 问题 3：大量操作走不到 LLM 判定，prompt 无法影响结果

权限判定是多层结构，前置静态规则会先于 LLM 分类器返回结果：

┌─────────────────────────────────────────────────────────────────┬────────────────────────┐
│ 前置判定类型                                                    │ 是否进入 LLM 分类器    │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ workingDirectory（工作区边界）                                  │ ❌ 直接 allow/ask/deny │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ safetyCheck + privateRuntimeData（classifierApprovable: false） │ ❌ 硬拦截              │
├─────────────────────────────────────────────────────────────────┼────────────────────────┤
│ safetyCheck + classifierApprovable: true                        │ ✅ 进入分类器          │
└─────────────────────────────────────────────────────────────────┴────────────────────────┘

即使将来 prompt 可以自定义，用户最关心的"读取工作区外普通文件""在项目内任意写入"这两类操作，由
workingDirectory 规则直接判定，永远送不到分类器，prompt 对它们没有任何作用。用户无法通过调整
prompt 来获得期望的宽松/严格程度。

1. 可自定义 auto 判定的 prompt
    - 提供一种方式让本地 prompt 真正参与判定。可选方案：
        - 在 POST /mavis/api/v1/permission/check 请求体中携带本地 prompt 内容；或
        - 提供本地/自建判定服务的 endpoint 配置项

2. 可为分类器指定独立模型
    - 修复 defaultLightModel 被无条件覆盖的问题，使其真正生效


3. 让 prompt 能影响到 workingDirectory 类判定
    - 或至少提供一个配置项（如 permission.autoBoundaryPolicy）来控制"工作区外访问"的默认行为，避免这类操作完全绕过 LLM 判定、导致用户的 prompt 配置对其无效