✨ 安装页标出不生效的指令与 GM 能力

[CodFrm]

Checklist / 检查清单

• Fixes mentioned issues / 修复已提及的问题
• Code reviewed by human / 代码通过人工检查
• Changes tested / 已完成测试

背景

安装前看不出脚本里哪些声明脚本猫不会执行。以 issue 里的 @exclude-match 为例：脚本猫的匹配链路只认
@match/@include/@exclude（src/pkg/utils/url_matcher.ts），这条声明被 metadata 原样保留却从不参与匹配，
本该被排除的页面照样会运行脚本；安装页对此只字不提，装完也不会有任何提示。#931 的反馈者正是「翻文档才发现原来不兼容」。

动手时发现真正缺的不是 UI，而是没有一份「脚本猫支持什么」的数据，现有三份东西互不相识：

• 编辑器的「未定义标签」判定取自悬浮提示表（monaco-editor/langs/*.ts 的 prompt 键，一张翻译表）；
• ESLint 的合法 header 集合取自 packages/eslint/ 对 eslint-plugin-userscripts 的覆盖，描述的是 TM/VM/GM 的支持情况；
• GM 能力的真相只在 GMContext 注册表里，而它由装饰器在 content 上下文载入时填充。

两份列表已经漂移（allFrames/require-css 在 ESLint 覆盖里、不在悬浮提示表里）。另外 userscripts/compat-grant
与 compat-headers 两条规则在 plugin 的 configs.recommended 里是 off，仓库也从没设 settings.userscriptVersions，
所以那两个覆盖文件今天只影响「名字合不合法」，并不做兼容性判定。

本次改动

三个提交，可分开审：

1. ♻️ 兼容性判定收敛为一张支持表 — 新增 src/pkg/utils/script_compat.ts 作为唯一判定来源。判定是二元的：
指令要么被脚本猫消费，要么写了也不生效，不分兼容程度。收录标准写在文件头——「会被消费」或「不消费但也不改变脚本
运行行为」（著作信息、脚本站元数据），只有会改变别家管理器下脚本行为、而脚本猫没实现的指令才刻意留在表外。
GM 能力静态镜像注册表，由新增的 GMContextApiNames() 双向守卫。编辑器的已知标签集合改用这张表，不再随语言包重建。
随之修正两处既有误报：@antifeature:<locale> 此前不在本地化后缀规则内被当成未定义标签；@definition 是脚本猫
自有指令却不在 ESLint 的合法 header 集合里。另加 parseMetadataLines，与 parseMetadata 共用 HEADER_BLOCK/META_LINE
但逐条保留行号——诊断必须与运行时解析看到同一批指令。

2. ✨ 安装页标出不生效的指令与 GM 能力 — 标记就近长在它所属的权限行上，不另起一张卡：不受支持的 @grant
直接替换权限行里原有的 chip，匹配类声明（@exclude-match）追加到「运行网站」行，归不到任何权限类别的
（@sandbox、@top-level-await）落在新增的「其他声明」行。说明走浮层（鼠标移入与键盘聚焦都能开），点击 chip
恒为跳转：展开代码卡、滚动到该行并选中。含义不只靠颜色传达，每枚 chip 带禁止图标与「不生效」的无障碍名。
两处折叠形态会藏掉标记，一并处理：权限一项没变时整卡本会塌成一行，有不生效项时不塌；移动端有标记的类别默认展开。
文案补齐 10 个语言包。

3. 🐛 不生效标记的浮层不再吞掉文档链接与相邻浮层 — 真实会话验证时发现的两处交互缺陷，见下。

实现考虑

不在安装页跑 ESLint worker。 issue 的 implementation guidance 提到复用编辑器的 lint 链路，没有采用：eslint_config
是用户可改的（src/pkg/config/config.ts），用户关掉规则提示就没了——把安全相关的提示挂在用户的 lint 偏好上是错的；
安装页是信任决策页，要确定、要快，不该为此拉进 linter worker bundle。标记全部由 metadata 静态派生。

不扫描正文里的 GM 调用。 @grant 本来就写在 metadata 里，不需要扫正文；正则扫 GM_xxx 误报率高，属于编辑器那侧的事。

@definition 按信息类处理（不标记）。 它是脚本猫自己文档化的编辑器指令，但全仓库没有任何消费方。在它被实现或从
文档撤下之前，对着脚本猫自己的文档报警只会让人以为是 bug。这条在 script_compat.ts 里写了注释，属于已知的待决项。

代码定位要求 diff 预览也能拿到实例，为此 CodeEditor 新增 onReady（普通与 diff 两条分支都触发），revealLine
在 diff 预览里定位到修改侧。这连带修掉一个既有缺陷：此前 onEditorMount 只在普通分支触发，更新安装页（有 diff）
的代码骨架永远收不起来。真实浏览器确认它被 monaco 盖住、不影响观感，问题在 role=status + aria-busy 一直留在
无障碍树里说「正在加载代码」。tests/mocks/CodeEditor.tsx 此前无视 diff 一律回调，正是它让这个缺陷在单元测试里
看不出来，现已与真实实现对齐。

已知限制

• 判定是二元的，按维护者口径不做「部分支持」一档。像 GM_setClipboard 只支持字符串这类行为差异不会在安装页出现。
• 支持表的「信息类」名单是人工维护的开放集合；别家将来新增的纯展示型 header 会被标成不生效（文案是「不支持该声明，
  安装后会被忽略」，对信息类不算错，但是噪音）。新增时往 INFORMATIONAL_TAGS 补一行即可。
• 本 PR 只做检测与呈现，不实现 @exclude-match（[Compatibility] Add support for @exclude-match #1714 单独跟踪）。标记不阻断安装。
• @grant 不区分「别家有但脚本猫没实现」和「拼写错误」，统一一句文案。要区分需把 eslint-plugin-userscripts 的
  grant 数据带进安装页 bundle，收益不抵成本。

建议审查重点

• src/pkg/utils/script_compat.ts 的 CONSUMED_TAGS / INFORMATIONAL_TAGS 两份名单——这是全部判定的根，逐条都值得看一眼。
• 编辑器「未定义标签」判定换源后的行为变化：原先取自悬浮提示表，现在取自支持表，两者不完全重合。
• deriveCompatMarks 里 metadata 键与代码行的对齐方式（src/pages/install/compat.ts）。
• CodeEditor 新增 onReady 与 onEditorMount 的职责划分。

关联

close #1713
相关：#931（兼容性跟踪）、#1714（@exclude-match 支持本身）

验证

• pnpm run lint：prettier / tsc / check:i18n / check:issue-templates / eslint 全通过。
• pnpm run test:ci：4781 passed（空载）。并行满载时 src/pages/options/routes/Tools/NetworkRules/ 的
  850ms UI budget 用例会超时（观察到 3~19 例不等），同一批用例空载连续三次全绿；这是 ⚡️ 降低网络规则跨页测试成本并固化测试约束 #1734 自己记录的既有限制
  （「本地并行运行整个 NetworkRules 目录时…会出现 worker contention 超时」），与本次改动无关。另外
  useInstallData.test.ts 的「技能安装成功后同样走按钮状态机与延时关闭」在满载下出现过一次超时，未再复现。
• 新增用例：script_compat.test.ts（支持判定 + 与注册表/ESLint header 集合的双向一致性守卫）、
  script.test.ts 的 parseMetadataLines、install/compat.test.ts（派生与定位）、CompatChip.test.tsx
  （浮层、跳转、互斥、无行号兜底）、PermissionRow/PermissionCard/CodePreview/CodeEditor/App 的接线与折叠形态。
• 真实扩展会话（pnpm run build 后加载 dist/ext，Playwright 驱动安装页）覆盖：三枚标记分别落在正确的权限行、
  卡头徽章计数、受支持能力不带标记、悬停浮层、鼠标移入浮层后文档链接可达、悬停切换只保留一枚浮层、点击跳转在普通
  预览与更新态内联 diff 下都滚动并选中目标行（diff 下 monaco 会自动展开折叠的 unchanged region）、更新态代码骨架
  已收起、暗色主题、全部受支持的脚本零标记。
• 修复前基线同样在真实浏览器取得：改动前的构建上更新安装页的 code-skeleton isVisible() 恒为 true。

Screenshots / 截图

[cyfung1031]

这个做法有点古怪吧
本来是，ScriptCat里记录的是「已支持」的，所有「已支持」以外的都标记为不支持

但看截图来说，你是用记录「不支持」的方式来实现。不然怎么知道「@exclude-match」是放在 运行网站
这个做法超奇怪
那么日后如果有其他的 syntax, 例如 @match-website-only，它会怎么处理？没写在「不支持」就是支持了？还是乱放一通

「@exclude-match」充其量只是一个例子。

[cyfung1031]

记录不支持的syntax这个做法超白痴
不支持的有无数的多
说不定明天 TM FM 又会加一堆新syntax
这种列表的更新一定不会追得上实际

[cyfung1031]

另外，如果要标记「不支持」，应该也要标记「仅限ScriptCat」（那堆CAT_XXXXXX）
其他脚本管理器不支持。只有ScriptCat支持。这些也应该要显示出来告诉一下