ISSUE-0093：两个独立窗口入口不可达¶
现象¶
src/entrypoints/results/（App.tsx + index.html + main.tsx + style.css）
仍在 WXT 的入口列表里、会被打包进扩展产物，但用户没有任何途径打开它。
settings 独立窗口同理，断点在上一环。
证据¶
① results 窗口：openWindow('results') 零调用¶
定义在 src/utils/open-windows.ts:19-24，全仓库除定义处外没有任何调用点。
🔴 这条链路早就有人发现了，只是没归档：
src/sections/content-search/index.tsx:142 的注释原文写着
「唯一发送方在 src/sections/page-results/index.tsx:105 整段已注释」。
也就是说注释掉发送方的那次改动，没有连带处理下游的入口与页面。
② settings 窗口：消息有 handler 无 sender¶
src/entrypoints/background/index.ts:224 if (type === 'open-page-settings') {
src/entrypoints/background/index.ts:225 await openWindow('settings');
openWindow('settings') 有真实调用，但触发它的 open-page-settings 消息
全仓库只命中这个 handler 自己，没有任何发送方。
为什么现在才发现¶
不是靠扫描器，是读代码的副产品：为盘点「产品功能矩阵」需要列出用户视角的功能面， 逐个核对入口时撞见的。
现有的 9 个 scanner 都是模式匹配（MV3 陷阱、React 生命周期、空 async、协议孤儿…），
scan:protocol-orphan 最接近，但它扫的是消息协议的定义/使用配对，
这两处恰好都「配对完整」——results 是「定义了函数没人调」，
settings 是「有 handler 没 sender」，都不落在它的判据里。
影响¶
- 打包体积：多一个入口 + 一个 React 页面
- 认知负担：读代码的人会以为这是活功能
- 若为它写产品文档，就是为死代码承诺用户行为
严重度低（不影响任何现有功能），但属于「声称即实存」的反向形态： 代码在，功能不在。
处置（待定，本 issue 先只归档不动手）¶
三选一，需要先确认历史意图：
1. 确认废弃 → 删：移除 entrypoints/results/、page-results/、
openWindow 的 results 分支、open-page-settings handler
2. 本该有入口 → 补：如果当初是想给用户一个独立结果窗口，把发送方接回来
3. 留作未来功能 → 标注：在 open-windows.ts 写明「入口暂缺，见 ISSUE-0093」
🔴 不建议直接删：page-results/index.tsx:105 那段被注释的发送方说明这是
有意为之的中间态，删之前要搞清当初为什么注释掉。
回归判据¶
若选择方案 1（删）：