[建议 / Feature] Bot channel: allow non-yolo run modes and remote permission approval via Telegram

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复提议 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

对话 / Agent 交互 · Agent chat / interaction

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

使用场景 · Use case

Bot-created tasks are hardcoded to yolo run mode. Sending /mode (list or set)
always returns: "This bot is locked to yolo run mode and cannot be switched."
This is unconditional in the bots runtime (the modeLocked path) — there is no
setting in Manage bots, bot-config.json, or anywhere else to change it.

建议方案 · Proposal

1. Allow bot tasks to run in non-yolo modes (build / plan), or at least provide
   an opt-in toggle in Manage bots (e.g. "Allow non-yolo run modes for this bot").
2. When the agent needs a permission decision, relay the request to the chat as
   an Approve / Deny card, and apply the response to the running session.

预期价值 · Expected value

Start a long-running task, walk away from the PC, and keep confirming actions
from the phone. Today the persistent channel (bot) can't do this at all because
of the yolo lock — auto-approval is the only option, which is a security concern
for destructive commands. The only remote approval path is Remote Control (a
temporary QR mirror of the whole window), which is not persistent and requires
re-connecting each time.

你认为的优先级 · Your perceived priority

中 · Medium

你使用的 ZCode 版本 / 环境 · ZCode version / environment

ZCode 3.8.1 (Windows 10), Telegram bot channel, bound workspace

补充材料 · Additional context

Most of the infrastructure already exists in the bot protocol — permission
cards (permission.respond), plan approval cards, and elicitation question cards
are implemented, and the "approve" command is already whitelisted as always
allowed. It looks like the only missing piece is removing/gating the hardcoded
yolo lock for /mode and routing pending permission requests of the active task
to the chat, for example Claude Code's ecosystem solves the same need with remote-approval
plugins that forward permission prompts to Telegram with Allow/Deny buttons —
this pattern works well in practice

Start in the bots runtime at the modeLocked path and review the existing permission.respond, plan approval, elicitation cards, and approve command handling. Trace how a bot task receives mode changes and how pending permission requests are associated with the active session. Done means non-yolo modes can be configured or selected safely, and permission requests reach the chat with Approve/Deny responses applied to the running task.