✅ 统一 example/tests 内部结构，去除 innerHTML 直写

[cyfung1031]

Checklist / 检查清单

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

背景

延续 #1631 的评审结论：@cyfung1031 在该 PR 中明确反对抽出共享测试框架
（sctest.js）并让每个用户脚本 @require 它——核心理由是每个
example/tests/ 下的用户脚本测试应当独立、自包含、一眼看完全部逻辑，
不应该为了"统一"而强行套用外部框架，也不应该发明一套自制 UI/断言系统。
本 PR 是与 #1631 完全相反的方向：不引入任何共享文件或 @require，只在
每个文件内部做结构整理。

本次改动

对 example/tests/ 下全部 15 个测试脚本做统一的内部结构整理（每个文件
独立处理，互不引用）：

• 将与具体测试对象无关的"工具代码"——计数器、test/assert 断言函数、
  控制台格式化、结果面板 DOM 生成、交互等待辅助函数等——收拢到内层 IIFE，
  以对象形式 return；外层 IIFE 通过解构参数接收这些函数，函数体内只保留
  原有的测试内容（GM API 调用、断言、执行顺序），写法和 UI/UX 基本不变：

  (async ({ test, assert, ... }) => {
    // 实际测试内容，与改动前逻辑一致
  })((() => {
    // 跟测试对象无关的基础设施
    return { test, assert, ... };
  })());

• 同类概念在各文件间统一命名：test/testAsync/assert/assertTrue/
  printSummary/showResultPanel（仅在该文件本身确实存在对应概念时才使用，
  不强行引入用不到的名字；例如 gm_xhr_test.js/gm_download_test.js/
  gm_xhr_redirect_test.js 本身用的是 pass/fail/skip 风格，予以保留）。

• 将所有 .innerHTML = / insertAdjacentHTML(...) 替换为
  document.createElement/textContent/appendChild/style.cssText
  构造，视觉效果不变，避免 CSP 不兼容问题（涉及
  early_inject_content_test.js、early_inject_page_test.js、
  gm_download_test.js、gm_value_test.js、gm_xhr_test.js、
  gm_xhr_redirect_test.js）。

实现考虑

• sandbox_test.js 在 IIFE 外还有必须保持非严格模式的顶层代码
  （var testVar1001、mpt 等），而带解构参数的函数不能带
  "use strict" 指令序言，因此该文件外层改用单一 helpers 参数、
  内部再 const { ... } = helpers 解构，其余文件均去掉了外层的
  "use strict"（严格模式语义保留在内层基础设施 IIFE 中）。
• gm_value_test.js（✅ 抽离 example/tests 共用测试框架 (sctest) 并全量迁移 14 个测试脚本 #1631 中标注为刻意不套用统一断言框架的交互式
  多 iframe dashboard 演示）未强行引入 test/assert，只对其原有的
  DOM 构造类工具函数做了同样的"工具代码后置"处理。
• 部分文件的断言参数顺序在改名时统一为 assert(expected, actual, message)
  （如 gm_xhr_redirect_test.js 原 assertEq(actual, expected, msg)），
  已确认所有调用点同步交换顺序，报错文案语义不变。

已知限制

• 未新增任何共享文件或本地 @require；每个脚本依旧可独立复制粘贴运行。
• 未改变任何测试用例的判定逻辑、期望值、执行顺序或 UI 视觉效果，仅做结构
  整理与断言/结果面板 CSP 加固。

建议审查重点

• 各文件重命名（assertEq→assert、testAsync→test、
  assertSame→assert、myResolve→resolveNext 等）的调用点是否全部
  同步，尤其是 gm_xhr_test.js（约 277 处）和 gm_download_test.js。
• gm_download_test.js/gm_xhr_test.js/gm_value_test.js 中替换
  innerHTML 的手写标签渲染函数（renderMarkup/buildLogLine/
  appendInline 等）是否真的走 DOM API 而非字符串拼接后单点赋值
  innerHTML。
• sandbox_test.js 的 helpers 单参数写法是否符合预期（因
  "use strict" 限制而与其余文件的解构参数写法略有不同）。

验证

• node --check 对 example/tests/ 下全部 15 个文件均通过（仅语法检查，
  不执行，因为文件依赖浏览器/GM 全局对象）。
• grep -nE '\.innerHTML\s*=|\.insertAdjacentHTML\(' 对
  example/tests/*.js 无匹配。
• grep -n '@require' 确认仅保留改动前已有的外部 CDN jQuery 引用，未新增
  任何本地/共享脚本引用。
• 独立 subagent 复核：对全部 15 个文件逐一比对改动前后的差异，确认重命名
  调用点计数一致、断言参数顺序变化处语义不变、setTimeout 延时数值未变、
  UserScript 元数据块逐字节不变、结构确为约定的双层 IIFE 形状；未发现任何
  行为回归或遗漏调用点。
• git commit 前置 hook（tsc --noEmit、Prettier、lint）均通过（example/
  目录本身被排除在 lint/format 范围外，仅命中预期的 ignore 警告）。

example/tests/ 目前尚未有针对这些脚本的常驻自动化 e2e，故本次验证以
静态检查 + 独立差异复核为主，未做浏览器内实跑（这些脚本本身就是手动/
半手动的功能演示与验证脚本）。

[CodFrm]

example/tests/ 下的用户脚本测试应当独立、自包含、一眼看完全部逻辑，

不应该为了"统一"而强行套用外部框架，也不应该发明一套自制 UI/断言系统。

你的观点都站不住脚，这个重构完全不影响阅读，反而是提升；也没有发明新的断言系统，都是和jest、vitest这些通用的统一函数签名，没有自制

比如 UI 面版，甚至可以封装好，将测试的代码展示到页面上，这样反而更加的清晰

[cyfung1031]

按 PickInvariant 做了一个“改动前后能否重建同一执行语义”的对比，这里有一个确定的行为回归，以及一个 CSP 边界没有闭合的问题：

1. gm_xhr_redirect_test.js 的 enableTool 守卫失效了一部分（χ：执行顺序/拓扑回归）。

   改动前是：

   (function () {
     "use strict";
     if (!enableTool) return;
     // 创建并 append panel
   })();

   现在是：

   (async (helpers) => {
     if (!enableTool) return;
     ...
   })((() => {
     // 这里已经创建并 append panel
     return helpers;
   })());

   JS 会先求值调用参数，所以即使把 enableTool 改成 false，右侧 helper IIFE 仍然会先创建 <style>、构造并 append #gmxhr-test-panel，之后外层才 return。也就是说原来的“关闭工具 = 无任何 UI/DOM 副作用”已经不能重建。

   最小修复建议：把 panel 构造改成惰性的 showResultPanel()，在 if (!enableTool) return 之后调用；或者把 guard 提到整个调用表达式外面。

2. “去除 innerHTML 后避免 CSP 不兼容”这个结论目前不成立（B：CSP sink 边界缺失）。

   例如同一个文件现在仍然是：

   const style = document.createElement("style");
   style.textContent = `...`;
   panel.appendChild(style);

   这仍然是 inline <style>，会受 style-src / style-src-elem 限制；另外几个手写渲染器里还有 el.style.cssText = ...，会受 style-src-attr 限制。createElement/textContent 解决的是 HTML 字符串 sink（以及 Trusted Types 一类问题），不能推出“样式 CSP 已兼容”。

   如果本 PR 的目标只是去掉 innerHTML，建议把 CSP 加固的表述收窄；如果目标确实包括严格 CSP 页面，则还需要把 <style> / cssText 这些 sink 一并替换（例如 constructable stylesheet，元素样式尽量逐属性设置），并加一个实际带 style-src/style-src-attr 的浏览器验证。

PickInvariant 的对比见证很直接：enableTool=false 在改动前后得到不同 DOM 副作用；而“无 innerHTML”在允许/禁止 inline style 的两种页面上仍可能得到不同 UI 结果。前者是当前代码的确定回归，后者是当前验证无法覆盖的接口边界。