[Feature Request] 多任务并发时增加冲突预检（session 混用 / 同域登录态冲突检测）

[xiyanjun]

背景

在同一个浏览器里用 bsk 并行跑多个自动化任务时，存在两类互相干扰，且当前无任何预检机制：

1. session 混用：多个任务共用了同一个 session id，导致共用同一个 Agent Window，标签页和 @eN 引用互相串。
2. 同域登录态冲突（更隐蔽）：所有 session 共享浏览器同一套 cookie。两个任务若操作同一个登录态站点（如企查查 qcc.com），登录态和页面状态会互相覆盖，产生数据污染，且无报错、极难排查。

期望行为：调用前冲突预检

建议新增 bsk preflight 子命令，内部复用 session list + tab list，输出分级冲突报告：

级别	冲突类型	判据
P0	同域登录态冲突	目标域名 与 任一活跃 session 的 agent 标签页域名重叠
P1	session 混用	预期并行任务数 > 活跃 session 数
P1	标签页争用	要借用的用户标签页已不在 user scope
P2	无冲突	域名零重叠、session 独立

原型验证（本地已跑通）

用一个纯标准库 Python 脚本（复用 bsk session list --json + bsk tab list --scope all --json）实测，三场景全部命中：

── 冲突预检报告 ──
  P0  目标 www.qcc.com 与 session <session-id> 的 agent 标签页同域（qcc.com）
      → 共享 cookie，登录态会互相覆盖
结论： 存在 P0 同域冲突，建议【串行执行】或【切换到不同浏览器实例】隔离登录态。
exit=2

退出码：P0=2 / P1=1 / P2=0，便于 Agent 编程化判断。

冲突处理策略（开放讨论）

检测只是第一步，冲突出现后如何处置想听下官方/社区意见：

• ① 串行排队（域锁）：同域任务排队，简单但吞吐下降
• ② 多浏览器实例隔离：开第二 Chromium profile 真正隔离 cookie，最彻底但需用户手动准备
• ③ 严格拒绝（strict）：P0 直接拒绝启动，最安全
• ④ 只读白名单：只读放行、写拦截，精细但有误判风险

如果暂时不做 CLI 命令

也建议先在 SKILL.md 的 Mandatory workflow 里增加「任务启动前预检 session 与域名冲突」这一步，避免两个任务挤进同一个 Agent Window。