feat: improve bot topic collaboration

[DeepColds]

Summary

• Keep dispatch assignments inside the current topic by default, while preserving new-topic behavior for chat-scope sessions.
• Add Linux-friendly Mira env/cookie handling and forward Mira env vars through tmux/zellij backends.
• Add bot/session controls: idle-close reminders, interrupt-turn button, configurable passthrough slash commands, auto-reply chat whitelist, and tmux UTF-8 locale handling.

Validation

• pnpm vitest run test/dispatch.test.ts
• pnpm vitest run test/tmux-backend-env.test.ts test/cli-adapters.test.ts test/mira-output.test.ts
• pnpm vitest run test/bot-config-editor.test.ts test/bot-registry-grant.test.ts test/card-builder.test.ts test/command-handler.test.ts test/event-dispatcher.test.ts test/tmux-env-isolation.test.ts test/idle-close-reminder.test.ts
• pnpm tsc --noEmit

[deepcoldy]

Worktree review @ head 37e914c。tsc 0 错误，全量单测（PR 基线，排除 e2e）229 文件 / 3540 例全过。整体实现质量不错，但有 2 个 🔴 阻断 + 若干 🟡，且与最新 master 冲突面很大，合并前必须 rebase。

🔴 阻断

1. idle-close 提醒默认开启，部署即「卡片风暴」
config.idleCloseReminder.enabled 默认 true（BOTMUX_IDLE_CLOSE_REMINDER_ENABLED 未设即开）。生产单机现状是 ~290 个 active 会话、绝大多数闲置远超 24h 且 worker 已挂起（liveWorker=false 直接放行）。daemon 升级重启后 10s 的首轮扫描会一次性向数百个旧话题群发提醒卡，必撞飞书限流，也会把所有沉睡话题全部顶起来打扰用户。建议：默认 off（显式 opt-in），或至少加 per-scan 发送上限 + 首轮按 createdAt 错峰。另外发送失败不落 sentAt，每 30min 会对同一批失败会话反复重试，限流下会持续风暴。

2. dispatch 默认改为「追加当前话题」后，thread-scope 会话失去开新子话题的能力
resolveDispatchTarget 把 thread-scope 会话的无 --into 调用一律隐式 into 当前话题，且没有任何反向开关（没有 --new-topic 之类的逃生阀）。在话题群里跑编排的 bot 从此无法 fan-out 子话题——这是对已上线的 orchestrate 工作流（skills/definitions.ts 自己也承认改了语义）的硬行为变更。oncall 场景的诉求合理，但至少要补一个显式 --new-topic/--seed 让旧用法可达，否则话题群编排直接退化成单话题串行。

🟡 非阻断

1. decideRouting 的 omt_ seed 启发式波及全部消息：rootId===threadId && startsWith('omt_') → anchor=messageId。该形状目前只在「bot 发的顶层种子」上观测过；若飞书对话题内回复也可能投递这种形状（未证伪），每条回复都会被当成新 seed 另起会话，peer bot 在已有话题里 @ 我们也会被劈进新会话。建议真机对「话题内 bot 回复」抓一次事件 payload 实锤后再合。
2. grant replay 用请求时刻的 ownsSession 快照：owner 几分钟后才点同意，期间该 anchor 可能已被别人开了会话；快照为 false 时会走 handleNewTopic 再 spawn。建议 replay 时重新 isSessionOwner 现算。
3. MIRA_COOKIE_HEADER/MIRA_SESSION 进 tmux pane 环境白名单：登录凭据从此可被任何能 attach 该 pane / 拿到可写终端链接的人 tmux show-environment 读走。建议评估是否走文件（0600）而不是 env 透传。
4. 提醒卡「保留会话」和「稍后提醒」两个按钮行为完全相同（同一个 idle_close_keep + 相同 snooze_ms），用户会困惑；要么去掉一个，要么给不同 snooze。
5. 与最新 master 冲突 12+ 文件（daemon.ts/cli.ts/card-handler/bot-registry/dashboard-ipc…，master 昨天刚合 PR#186 原子写改造 23 文件；docs-site 还撞上 zh/ 目录重构的 modify/delete）。rebase 后需重跑全量。
6. 一个 PR 混了 5 个互不相关的特性（话题协作、Mira Linux、idle 提醒、打断按钮、passthrough/白名单/locale），回滚和灰度都只能整包。下次建议拆开。

当前话题追加模式的小问题

--standby 与隐式 current-thread 组合时输出 mode: 'current-thread'（target.implicit 优先于 standby 判断），调用方无法区分是否真的派了简报；建议 mode 区分 standby-current-thread。

[deepcoldy]

已代为合入最新 master 并落实 review 修复（37e914c8 → d7e2ab6，6 个 commit）：

合 master（merge commit d02adb4），12+ 文件冲突全解，其中两处按 master 既有机制收编：

• ❌ passthroughCommands 整块撤销：master 已有 customPassthroughCommands（归一化 + daemon 命令遮蔽过滤 + /list-slash-command），功能重复且本 PR 版本缺遮蔽过滤（自定义 /status 会劫持 daemon 命令）。/help 渲染 per-bot 生效清单的改进意图保留，改用 resolvePassthroughCommands
• ♻️ autoReplyWithoutMentionChats 收编进 resolveGroupMentionMode(larkAppId, chatId?)：master 已有三档 @ 策略，白名单群 = per-chat 'never'，与 bot 级 'never' 走同一 relax 闸，所有读 mention mode 的路径（含共享话题 seeding）语义一致

review 修复：

• 🔴 闲置提醒默认关（须 BOTMUX_IDLE_CLOSE_REMINDER_ENABLED=true 显式开）+ 单轮上限 10 张 + 「保留会话」(7d)/「稍后提醒」(24h) 两按钮区分
• 🔴 dispatch 加 --new-topic 逃生阀（与 --into 互斥），thread-scope 编排会话仍可 fan-out；standby 隐式追加时 mode 输出区分 standby-current-thread
• 🟡 授权重放改为执行时现算 ownsSession（防旧快照在已有会话的 anchor 上二次 spawn）
• 🟡 bot 发件人 auto-start 助手补 source === 'topic-chat' 守卫：master 普通群 new-topic 模式会产出同样的 {thread, anchor=messageId} 形状，无此守卫外部 bot 顶层消息会在普通群误触发
• 补 zh/en bots-json 文档行（autoReplyWithoutMentionChats）

验证：tsc 0 错；全量 unit 4332/4335 过，3 fail = master 既有基线（session-lifecycle-hooks + transfer-session，主 checkout 同样挂）。

仍未处理（留给作者/后续）：

1. omt_ seed 启发式建议真机抓一次「话题内 bot 回复」的 payload 实锤——若回复也带 root_id=thread_id=omt_ 形状会被劈成新会话
2. MIRA_COOKIE_HEADER/MIRA_SESSION 透传进 tmux pane env，登录凭据可被任何能 attach 的人读走，建议评估改文件（0600）传递