feat(dashboard,worker): 直达入口恢复无边框工作台，并修 Web 终端滚动条样式

[linvon]

改了什么

1. 直达入口进沉浸式工作台（feat(dashboard)）

• 新增 src/core/workbench-shell.ts：定义工作台沉浸式标记 botmuxWorkbenchShell=immersive，以及服务端三处共用的 302 目标常量（零依赖，服务端与 web bundle 共用一份）。
• 三个直达入口改为 302 到带标记的 hash：/workbench、/workbench/dock 跳板（dashboard.ts）、?t= 登录一跳（dashboard/auth.ts）、/workbench-ticket/<ticket> 兑换（dashboard/workbench-ticket.ts）。
• workbenchSpaUrl（无凭证兜底链接、平台托管时 CLI 打印的工作台链接）同样带标记。
• 前端 client-shell.ts 新增 readDashboardWorkbenchShell，启动时把标记与 botmuxClientShell 一样从 hash 提升进查询串（之后 hash 导航不丢）；app.tsx 壳判定认到标记即渲染无边框壳。
• docs/agent-workbench.md 补充入口形态说明。

2. Web 终端滚动条改细（fix(worker)）

• 给 #terminal .xterm-viewport 补滚动条样式：轨道透明、拇指细且半透明、悬停加深。标准 scrollbar-* 覆盖 Firefox 与 Chromium 121+，::-webkit-scrollbar 覆盖旧 Chromium / WebKit。

为什么

• feat(dashboard): Calm Console 全面改造——设计 token 体系 + 注意力优先布局 + 全局反馈系统 #948 之后 #/agent-workbench 只在桌面/移动客户端壳里无边框，浏览器一律套 Dashboard 外壳。于是 /dashboard 卡片「打开工作台」按钮、botmux dashboard 打印的工作台链接、常驻链接、短票兑换这些直达入口全部落进了带侧栏的壳，与「一整屏工作台」的定位相悖。改后直达入口恢复无边框；侧边栏「驾驶舱」进入不带标记，保持正常壳（保留 feat(dashboard): Calm Console 全面改造——设计 token 体系 + 注意力优先布局 + 全局反馈系统 #948「从侧栏进来要能回去」的意图）。标记不复用 botmuxClientShell：客户端壳还会过滤导航、拦 Workflow / Web 终端路由，网页直达入口不该被连带限制。
• 飞书内嵌 webview（以及任何用经典非悬浮滚动条的桌面环境）会把 xterm viewport 的原生滚动条画成白底粗条，压在暗色终端上非常扎眼。

影响面

• 模块：dashboard 服务端（auth 一跳、/workbench 跳板、短票兑换）、core/dashboard-url（workbenchSpaUrl）、dashboard web（client-shell、app 壳判定）、worker 提供的 Web 终端页样式。daemon 消息链路 / adapters / 卡片内容不涉及。
• 会话类型：与会话类型无关，只影响工作台入口 URL 的落点形态与终端页样式。
• 平台：飞书卡片按钮（PC AppLink / 移动端裸 URL）、CLI 输出、常驻链接、浏览器书签都会落沉浸式壳；桌面 / 移动客户端壳行为不变（仍由 botmuxClientShell 决定）。飞书 H5 免登的 returnTo 清洗器会丢 hash 查询串，这条路径与之前一致（未改）。终端页样式对桌面浏览器、工作台 iframe、飞书内嵌页是同一份 HTML，Reader / Classic 两种终端风格共用同一 viewport，均生效。

实际测试验证

• tsc --noEmit 通过；bun run build（含 audit:domains / audit-dist / audit-embedded）通过。
• vitest run --project unit：相关 15 个测试文件 471 项全绿，含新增用例：client-shell 标记读取 / 提升 / 不是客户端壳；auth /workbench、/workbench/dock 一跳目标；票据 302 目标；workbenchSpaUrl 带标记；源码钉死三处服务端目标取同一常量。全量 unit 套件失败项与同机 master 基线一致（均为 spawn / 环境类既有失败，本分支同条件下反而更少）。
• 隔离 HOME 起补丁版 dashboard（node dist/index-dashboard.js，端口 7999），Playwright 冷登录实测：/workbench?t=、/workbench/dock?t=、/workbench-ticket/<ticket> 三条都落到 /?botmuxWorkbenchShell=immersive#/agent-workbench(-dock)，无侧栏、有会话列表；改 hash 到 #/agent-workbench/<id> 后仍保持无边框；/?t=#/agent-workbench（侧栏形态）仍是正常壳。curl 核对三处 302 的 Location 与 set-cookie 与预期一致。
• 本机 fleet 已 switch:here + restart 跑本分支 live 验证：真实会话下 /workbench?t= 打开为无边框、打开终端面板与切换会话后保持；终端 iframe 内 getComputedStyle(viewport) 为 scrollbar-width: thin + 自定义 scrollbar-color，截图确认拇指细且半透明。

[deepcoldy]

非阻断建议（不影响本 PR 合入）：

src/dashboard.ts 的 PWA manifest 里 start_url: '/#/agent-workbench' 没带沉浸式标记。该 manifest 的注释自述定位是「permanent entry」、意图「launch straight into the session list, standalone and chrome-less」；但 #948 之后无标记的 #/agent-workbench 会落带侧栏的正常壳，「加到主屏幕」启动的结果与注释意图相反。

本 PR 已给其余直达入口（/workbench 跳板、?t= 登录一跳、短票兑换、卡片按钮、CLI 链接）补上 botmuxWorkbenchShell=immersive，建议顺手把 PWA start_url 也带上（一行）：

start_url: '/#/agent-workbench?botmuxWorkbenchShell=immersive',

或复用 src/core/workbench-shell.ts 的 WORKBENCH_IMMERSIVE_ENTRY。目前没有测试钉住 manifest 内容，可顺带补一条。

[deepcoldy]

技术评审通过，0 阻断。

沉浸式壳改动：服务端三处 302（/workbench 跳板、?t= 登录一跳、短票兑换）+ workbenchSpaUrl 统一带 botmuxWorkbenchShell=immersive，常量集中在 core/workbench-shell.ts 避免服务端与 web bundle 手写字符串漂移。前端壳判定 readDashboardClientShell() || readDashboardWorkbenchShell()，且沉浸式标记不复用 botmuxClientShell——导航过滤、路由重定向、Web 终端开关仍只认 client shell，直达入口不被连带限制，边界正确。

fragment 存活机制：标记放 hash 查询串，?t= 登录跳转剥查询串时随 fragment 保留（浏览器跟随无 fragment 的 302 保留原 fragment），启动时提升进 search，之后选中会话改 hash 不丢。

验证：

• tsc --noEmit rc=0
• 受影响 6 个测试文件 254/254 绿
• 反变异确认 app.tsx 壳判定承重（删掉 || readDashboardWorkbenchShell() 测试立即变红）
• 对最新 master merge-tree 无冲突；真合并后 tsc + 254/254 绿
• CI 必需的 test check 曾因 test/unit-setup.ts afterAll 的 ENOTEMPTY teardown 竞态红（master 既有、本 PR 未触碰该文件，7486 passed / 0 真实用例失败），re-run 后全绿

非阻断遗留：PWA manifest start_url 未带沉浸式标记（#948 既有缺口，manifest 注释自述意图 chrome-less），已在 PR 评论建议顺手修或开 follow-up，不阻断本 PR。