fix(macos): 响应 PR #18 审查意见并评估快捷键绑定方案

[wendaining]

背景

针对 PR #18（fix: improve macos option-r input），Codex Review 提出了以下两项重要的改进建议：

1. 自定义快捷键时仍无条件绑定 ®（Option+R）：

   • 当前 PR 在检测到 macOS（$OSTYPE == darwin*）时，无条件执行了 bindkey '®' _recall_search（以及 bash/fish 的对应绑定）。
   • 如果用户在 config.toml 中将 ui.search_key 自定义为了其他按键（例如 ctrl-t 或 ctrl-x ctrl-r），该脚本依然会拦截 ®，导致配置不彻底且用户无法正常输入特殊字符 ®。
   • 改进点：应仅在当前配置的语义快捷键为 alt-r（默认值）时，才在 macOS 上回退绑定 ®。

2. 文档说明与安装脚本/体检命令（install.sh / doctor.rs）的表述冲突：

   • PR 修改后的 README 宣称 recall 原生兼容 Option+R 打出的 ®，终端无需额外设置；
   • 但 install.sh（224-234 行）依然提示用户必须开启 Option-as-Meta 且在 macOS 默认推荐 ctrl-x ctrl-r；
   • src/commands/doctor.rs（153-158 行）也依然将终端输入 ® 判定为未配置 Option-as-Meta 的异常；
   • 改进点：需要同步统一 install.sh、doctor.rs 与 README 的诊断文案和推荐逻辑。

---

关于替代方案 Command+R 的可行性评估

经技术核查与调研：Command+R（⌘+R）在纯 Shell 层不可作为开箱即用的解决方案。

原因如下：

1. 终端层截获，PTY 无字节输入：
   • 在 macOS 下，Command（⌘）是操作系统与 GUI 应用的保留修饰键。Terminal.app、iTerm2、Alacritty 等终端模拟器默认将 Command 组合键用于 GUI 窗口与菜单动作，默认不会向底层 PTY 管道发送任何 ANSI/VT 控制转义序列。
   • Shell（zsh/bash/fish）运行在 PTY slave 端，根本接收不到任何键盘事件，因此无法通过 bindkey 或 bind 捕获 Command+R。
2. 快捷键冲突：
   • 在 Terminal.app 等终端中，Command+R 默认被分配给系统级菜单操作（例如重置/清空屏幕 Hard Reset）。
3. 实现成本过高：
   • 除非强依赖用户在各自终端模拟器（如 iTerm2 Key Mappings）中手动配置“将 Cmd+R 映射为自定义 Hex Code / Escape 序列”，否则无法在脚本中自动化实现。

---

建议跟进任务

1. 修正条件绑定逻辑：
   • 检查配置的快捷键是否为 alt-r，仅在匹配时才在 macOS 下绑定 ®。
2. 统一安装脚本与诊断信息：
   • 更新 install.sh 与 src/commands/doctor.rs，不再将 ® 报告为配置错误，明确说明已原生支持默认 Option+R。