feat: 侧边浏览器支持用户已有的密码管理器/钥匙串工具填充

> 本 issue 是一次功能调研的沉淀:**暂不实现**,先记录需求、方案与调研结论,以后有时间再做。研究背景是「让侧边浏览器支持用户已有的密码管理器/钥匙串工具填密码」,方向是复用用户现成的工具(1Password / Bitwarden 等),**不自建密码管理器、不搬运用户的 cookie/密码库**。

## 使用场景 / Use case

侧边内嵌浏览器(RSB,partition `persist:xdmaker-browser-app`)里,用户经常需要登录网站。钥匙串工具重度用户(1Password / Bitwarden 等)希望能像在普通浏览器里一样,用**自己已有的密码管理器**把账号密码填进内嵌网页的登录框,而不是手动敲、也不是让 Cindy 替他们保管密码。

## 当前问题 / Current limitation

侧边浏览器目前**没有任何密码填充能力**,用户只能手动输入或复制粘贴。而各条「让现成工具来填」的路子对标准 Electron `` 都有硬限制,调研结论如下:

- **系统级 Universal Autofill(1Password 的 Cmd+\)在 Electron webview 里拿不到网页 URL**:1Password 只能把 Cindy 当成「一个 app」做 app 级匹配,感知不到 webview 里当前网站,所以「按网站自动出对应登录项」不存在;而且它会校验目标 app 的代码签名(WebCatalog 等站点封装 app 曾因此被整体禁用)。Quick Access 手动搜索 → Autofill 是唯一较可靠路径,但无站点感知、首次要手动把条目链接到 app。参考:[Universal Autofill on Mac](https://support.1password.com/mac-universal-autofill/)、[About macOS Privacy & Security settings for Universal Autofill](https://support.1password.com/mac-universal-autofill-settings/)。
- **Bitwarden 桌面 app 目前没有系统级全局填充**(macOS 桌面端 autofill 仍在 roadmap 上,现阶段只提供 passkey 侧的 credential provider,不提供密码)。参考:[Bitwarden roadmap discussion #14156](https://github.com/orgs/bitwarden/discussions/14156)。
- **Apple 系统 AutoFill / iCloud 钥匙串对 Chromium/Electron 全关**:系统 AutoFill 只对 Safari + 原生控件生效;第三方浏览器接 iCloud Passwords 需要完整 Chrome 扩展 + native messaging,并且要以独立签名浏览器身份进 Apple 的浏览器白名单(macOS 15.4+ 起硬校验)。Electron `` 完全在这条管线之外。所以「用 Safari 插件 / iCloud 钥匙串填充」在我们的形态里**不是可选项**。参考:[Apple Platform Security — credential provider extensions](https://support.apple.com/guide/security/credential-provider-extensions-sec6319ac7b9/web)。
- **裸 Electron 41 直接加载 1Password/Bitwarden 的 Chrome 扩展会崩**:Electron 官方扩展支持自我定位为「面向 DevTools 的子集,完整扩展 API 兼容是非目标」,缺 `chrome.action` popup、`contextMenus`、`cookies`、`webNavigation`、`notifications`、`runtime.connectNative` 等,密码扩展加载时首行就会因 undefined API 报错。参考:[Electron extensions docs](https://www.electronjs.org/docs/latest/api/extensions)。

**对标 Codex desktop(基于其公开文档与产品行为):** Codex 的内嵌浏览器是自研 Chromium fork,自带原生密码管理器/autofill,并通过「Profile Import」从用户已装的 Chrome/Atlas **一次性导入 cookie + 密码**(本机原生解密,macOS/Windows only,Windows 需管理员提权解 App-Bound Encryption);它没有对 1Password/Bitwarden 的专门集成,第三方扩展是走 fork 自带的 `chrome://extensions/`。**这三条腿都建立在「自研 Chromium fork + 原生模块」上,标准 Electron + `` 无法直接复制**;而且它的 Profile Import 正是我们想避开的「搬用户密码/cookie 库」方向。参考:[Using the built-in browser in the ChatGPT desktop app](https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app)、[Codex app browser docs](https://developers.openai.com/codex/app/browser)。

## 期望方案 / Proposed solution

建议**分两步**,先低成本兜底,正式能力单独立项:

### 第一步(近零开发,先给 1Password 用户一个可用体验)
- 确保 macOS 包正规 Developer ID 签名 + 公证(这是 1Password Universal Autofill 愿意对 app 填充的前提);
- 侧边浏览器**不阻断粘贴**(所有密码管理器都兜底支持复制粘贴)。

这样 1Password 用户现在就能用 Quick Access 手动搜索 → Autofill / Cmd+\ 的 app 级填充把密码打进 webview 输入框——体验不完美(无站点自动匹配、首次需手动链接条目),但 Cindy **一行凭证代码都不用碰**,风险几乎为零。

### 第二步(正式功能,单独立项评估)
若要做成产品级「在 Cindy 浏览器里用自己的密码扩展填充」,唯一现实路线是引入 [`electron-chrome-extensions`](https://github.com/samuelmaddock/electron-browser-shell)(补齐了 MV3 service worker、`chrome.action` popup、native messaging 等),让用户**在 Cindy 浏览器里安装并登录自己的 1Password/Bitwarden 扩展**(注意:是重新装一遍同一个扩展、再登录一次,不是复用 Chrome 里已登录的实例)。有商业先例([Polypane 官方确认](https://polypane.app/docs/browser-extensions/) 1Password/Bitwarden/KeePassXC 可用)。`` 同 session 会注入 content script,可行。

需要接:扩展运行时、popup UI、每个 webview 手动 `addTab` 注册(密码扩展重度依赖 tabs/webNavigation)、service worker preload、crx 协议;并顺手补 `persist:xdmaker-browser-app` 这个 session 的 `setPermissionRequestHandler`/`setPermissionCheckHandler`(见下「相关既有缺口」)。

**这一步的代价必须先在产品优先级上权衡清楚,不适合顺手做**:
- `electron-chrome-extensions` 是 **GPL-3,商用需买付费/专有授权**;
- 该库截至 2026-07 已约 13 个月无提交,且 Electron 官方立场是扩展兼容「非目标」,每个大版本都可能碎(E40 曾出现 MV3 SW 回归、E41 恰好恢复、E43 又有新 storage 事件 bug),需要按扩展版本做回归测试或锁定已验证版本分发;
- 连桌面 app 生物解锁需走 1Password 官方 Add Browser(要求 app 经 Apple 签名且装在 `/Applications`),1Password 理论可通、Bitwarden 生物解锁未见公开成功案例。

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

- **Profile Import(对标 Codex,从 Chrome 导入密码/cookie 库)** — 排除。这正是「搬用户密码/cookie 库」方向,与本需求相悖;技术上标准 Electron 也做不到(需自写原生代码解密 Chrome `Login Data` + macOS keychain),且直接撞仓库凭证红线(`docs/dev-rules/credentials-and-local-storage.md`)。
- **Safari 扩展 / iCloud 钥匙串填充** — 不存在门。只对 Safari/WKWebView 生效,Chromium/Electron 无接入面。
- **Cindy 自建密码管理器 / preload 直接注入明文** — 排除。撞 `docs/dev-rules/electron-security-and-process-boundaries.md` §4(preload 不得读取或返回凭证明文)与凭证存储范式(只走 safeStorage、明文只留 main、对外只给存在性+尾指纹)。

## 相关既有缺口(实现任一步时应一并处理)

- 侧边浏览器 session `persist:xdmaker-browser-app` 在 main 进程从未被取出配置,**尚未设置 `setPermissionRequestHandler` / `setPermissionCheckHandler`**,与 `electron-security-and-process-boundaries.md`「加载远程内容的 session 必须按最小权限默认拒绝」不符。这是一个独立的 hardening 项,动这个 session 的方案应顺手补上。

---

*本 issue 由一次内部对标调研整理而成,仅记录需求与方案,暂不排期。*

This issue records research only and explicitly defers implementation. Start by reading docs/dev-rules/credentials-and-local-storage.md and docs/dev-rules/electron-security-and-process-boundaries.md, then locate the main-process setup for the persist:xdmaker-browser-app session. Done would require a separately scoped product decision and implementation issue; no specific change or acceptance test is defined here.

Written by the indexing model from the issue text.