【Bug】PreviewConfirm 模式下润色文本重复插入（嵌套重叠） #1014

问题描述

在使用 PreviewConfirm 输出模式（先预览润色结果、用户确认后再插入）时，最终插入目标应用的文本会出现重复：原始润色内容出现一次，且同样的内容还会嵌套在第一段文字的末尾几个字中间，形成"结尾重叠"的效果。

复现步骤

1. 在设置中将"选区润色输出模式"设为 PreviewConfirm（预览确认）
2. 在任意 Windows 应用（尤其是 Electron / Chromium 内核、QT、富文本编辑器）中选中一段文字
3. 触发选区润色快捷键，等待润色完成后在预览窗口点击"确认替换"
4. 观察目标应用中插入的文本

实际现象

插入文本出现两遍，第二遍嵌套在第一遍末尾数个字中间，例如：

润色后的完整内容润色后的完整内容整内容

（示意：前半段完整，后半段从某处开始重复）

期望现象

目标应用中只出现一遍润色后的文本，完整替换原来的选中内容。

根本原因分析

confirm_selection_polish_preview 在执行 Ctrl+V 粘贴之前，会调用 validate_selection_insertion_target。该函数在 Windows 上会向目标应用发送一次真实的 Ctrl+C 按键，以重新读取当前选区文本进行校验。

这次 Ctrl+C 会破坏许多 Windows 应用的活动选区状态，导致随后的 Ctrl+V 无法正确替换选中文本，而是在光标所在位置插入，从而产生嵌套重复的效果。

修复方案

在 PreviewConfirm 路径中，改用仅校验窗口身份（HWND）的验证函数，跳过 Ctrl+C 重读步骤。

理由：

• 用户已在预览窗口明确确认了替换操作，无需再次读取选区内容
• reactivate_selection_insertion_target 已经恢复了目标窗口的焦点和活动选区
• HWND 校验足以检测用户在预览期间是否切换了应用窗口

DirectReplace 路径（无预览直接替换）仍保留完整的 Ctrl+C 校验逻辑，因为 LLM 调用期间用户有可能已经移动或改变了选区。

环境

• 操作系统：Windows
• 受影响模式：SelectionPolishOutputMode::PreviewConfirm