feat(desktop): 在明确授权后复用现有 Chrome 会话

## 使用场景 / Use case

在 Cloudflare、Google Workspace、内部系统等需要登录或 2FA 的任务中，用户已经在日常 Chrome 中完成登录。希望 Cindy 在用户明确授权后连接该 Chrome 会话或指定标签页，复用浏览器自身已有的登录状态，避免在内置浏览器中逐站重复登录。

这是 #1322 第 4 项期望行为的独立 feature 跟踪。#1322 的修复范围只处理内置浏览器的可靠启动、disposing 恢复、设置重启后的状态重建，以及明确的一键恢复提示；Chrome 会话复用涉及新的授权、安全和分发边界，不应与该 bugfix 混在同一个 PR 中。

## 当前问题 / Current limitation

Desktop 内置浏览器使用独立、持久的 profile，与用户日常 Chrome 的 Cookie 和登录会话隔离。即使内置浏览器恢复正常，登录密集型任务仍需要重新登录和重复 2FA。

#70 已经详细分析了扩展 + native host、外部 CDP 验证和保持独立 profile 等路线，但它明确是路线决策 issue，不是实现 issue。本 issue 作为决策后的交付与验收入口，不预先替 #70 裁决具体技术路线。

## 期望方案 / Proposed solution

先完成 #70 的路线决策与必要的可行性验证，再实现一个受控的“连接现有 Chrome”能力。无论最终采用扩展 + native host 还是经批准的外部 CDP 桥，至少满足以下验收条件：

1. 只有在用户主动安装、连接或附加并明确授权后，Cindy 才能控制现有 Chrome；不得静默接管浏览器。
2. UI 明确显示当前连接的浏览器、profile 或标签页范围，以及 Chrome 的调试提示和平台限制。
3. 提供一键断开与撤销授权；断开、Chrome 退出或桥接故障后必须清除旧连接状态，并给出可执行的重新连接入口。
4. 不读取、导出或复制 Cookie、密码、profile 文件等凭证数据；登录态复用应来自 Chrome 自身会话与受支持的调试/桥接能力。
5. 独立的 Cindy 内置浏览器继续作为默认或可选兜底，不因外部 Chrome 不可用而阻断所有浏览器任务。
6. 对仅支持 Chrome、扩展安装、调试横幅、企业策略、Windows/macOS 差异等限制给出准确说明，并覆盖授权拒绝、撤销、断线和重连测试。

## 已考虑的替代方案 / Alternatives considered

- 继续只使用独立 profile：安全边界清晰，但无法解决重复登录和 2FA 成本。
- 让用户用 `--remote-debugging-port` 启动 Chrome：适合作为 #70 中的可行性验证，但长期体验和暴露调试端口的安全性需要单独评估。
- 通过 1Password/Bitwarden 等显式填充凭证：可以缓解登录输入，但不能复用现有会话，也不能覆盖所有 SSO/2FA 场景。
- 直接读取或复制 Chrome Cookie/profile：不接受，凭证和用户数据风险过高。

Start by reading issue #70 and completing its route decision and feasibility validation; no implementation files or tests are named here. Define the approved connection approach and verify the listed authorization, UI, disconnect, credential-isolation, fallback, platform, and reconnection requirements, including tests for refusal, revocation, interruption, and recovery.

Written by the indexing model from the issue text.