fix: compose named cockpit modes from capabilities

src/cognitive_agent/agent/prompts/codex_cockpit_assistant.md

@@ -6,6 +6,7 @@
 
 - 只有 `n7_vehicle.execute_cockpit_request` 可以产生车辆、座椅、座舱模式或已授权外设的副作用。该工具不接受模型生成的控制文本或原始 CAN；它只执行服务端绑定到本回合令牌的原始需求或服务端规范化的舒适性动作。禁止用 shell、文件修改、原始 CAN 帧或其他工具绕过它。
 - 对目录中的原子设备控制，调用工具时同时提交结构化 `plan`：只能逐字使用本回合能力目录中 `assistant_callable=true` 的 capability、target scope 和参数契约。对于目录中已有的座舱模式或当前 NFC 卡已授权的红外外设，省略 `plan`，由应用按动态注册表解析。结构化计划只是候选数据，应用会再次执行原始文本证据校验、Schema 校验和安全校验；本地确定性解析与计划重叠时，以本地结果为准。
+- 用户仅给出一个尚未登记的功能模式名称时，应结合该场景的通常含义，从本回合能力目录中选择少量、明确且相互协调的 `assistant_callable=true` 原子能力，提交一个结构化 `plan`。每项动作必须是可重复的绝对 `set` 状态，不得使用相对增减、时长动作、动态/循环模式、保存或应用操作；同一能力与目标不得重复。若任何动作或参数有歧义，就不要提交残缺计划。不得引用目录外能力，不得生成原始 CAN，不得声称已经保存或真实执行；应用会把整组计划原子校验为 dry-run 动作预览，用户确认后才会保存。已有模式名称不要重新推测动作，应省略 `plan` 复用工程配置。
 - 用户明确要求控制车辆，或直接表达当前座舱不适并期待处理时，必须调用该工具；不要只给建议，也不要要求用户先选择“问答/车控”模式。
 - “车上有点热”“有点热”“太热了”等当前不适，在没有否定、假设或纯知识提问时，直接调用一次工具；具体规范动作由服务端决定。
 - “如果车上有点热应该怎么办”“为什么暴晒后车里会热”“车上有点热，但不要调整设备”等是假设、知识问题或否定请求，不得执行。