macOS：只读命令隐式读取 Chrome Cookie，触发 Keychain 授权弹窗

## 背景在 macOS + Google Chrome 环境下，当本地 CLI 凭据不存在或过期时，执行只读命令（例如 `boss status` / `boss search`）会隐式尝试读取 Chrome 登录 Cookie。## 现象这个隐式读取链路可能调用 `browser-cookie3`、`/usr/bin/security`，并访问 Chrome Safe Storage，因此 macOS 会弹出 Keychain 授权窗口，要求输入登录钥匙串密码。在一次超时场景中，外层命令结束后，相关授权进程可能未及时退出，导致弹窗重复出现。对用户来说，`status/search` 只是查询操作，却产生了密码弹窗和阻塞。## 建议1. `boss status`、`boss search` 默认只检查 CLI 自己的本地凭据，不隐式读取浏览器 Cookie；2. 浏览器 Cookie 导入必须由用户显式触发，例如 `boss login --cookie-source chrome`；3. 浏览器 Cookie 提取失败或超时后，确保子进程被清理；4. `boss login` 默认继续使用二维码登录。## 桌面端只读方案我在本地验证了一种替代方案：用户继续在 Chrome 中登录 BOSS，CLI 通过已登录页面发起同源请求，只接收搜索结果和职位详情；CLI 不读取 `document.cookie`、Chrome Cookie 数据库、`__zp_stoken__`、Keychain 或 `/usr/bin/security`。这个方案适合桌面端的只读搜索和查看 JD，不解决无头服务器登录，也不是绕过 BOSS 风控。相关讨论：[Issue #16](https://github.com/jackwener/boss-cli/issues/16)、[PR #22](https://github.com/jackwener/boss-cli/pull/22)。

Start by running the affected read-only commands, `boss status` and `boss search`, and inspect the credential and browser-cookie login paths. Read Issue #16 and PR #22 for the existing discussion and proposed desktop approach. Done means read-only commands no longer trigger browser-cookie or Keychain access, explicit Chrome import remains available, and failed or timed-out extraction does not leave authorization processes running.

Written by the indexing model from the issue text.