test(PC-2): e2e 真崩溃注入（CDP Page.crash）取代假崩溃 + 两个 OPFS 写入窗口

背景（PLAN-v0.7.5.md 根因 5）：项目声称的崩溃语义一直没有被真实验证。
e2e 里的 `crashPage()` 实际是：
    win.__ms = null;  await page.close();
—— 那是**优雅关闭**：没有未完成 I/O、不经过任何崩溃窗口。于是
    `checkpointInterval: 999999999` + 不 close 的"崩溃恢复"用例，测的其实是
    "正常关闭后重开"。CI 注释却写着"e2e 覆盖真实崩溃注入（CDP Page.crash）"。

改动：
1. `crashPage()` 改用 CDP `Page.crash` 终止渲染进程（进行中的 OPFS 写入、
   未 flush 的缓冲、同步句柄全部立即消失）。实测要点：
   - `Page.crash` 之后 `page.isClosed()` 仍为 false，不能用它判成败；
   - OPFS 数据**在同一个 context 内**跨崩溃保留（新建 context 是另一份存储），
     因此崩溃后新开页面即可继续验证。
2. harness 增加两类真崩溃注入：
   - `insertNoAwait`：发起写入但不等待（`page.evaluate` 会等 Promise，
     因此"写到一半就崩"无法用普通 await 表达）；
   - `armCrashOnOpfsWrite({ phase })`：包装 `FileSystemWritableFileStream`
     的 `write`/`close`，在第 n 次调用处进入死循环，随后被 Page.crash 杀掉 ——
     对应 copy-on-write 的两个真实窗口。**注**：OPFS 用的是 createWritable，
     不是 `FileSystemSyncAccessHandle`（后者主线程不可用，实测）。
3. 新增两个用例覆盖上述窗口，并断言钩子**确实装上**（armed === true），
   避免"注入了但没走到"的假绿：
   - write 阶段崩溃 → 已确认数据完好；
   - commit 阶段崩溃 → 3 条旧数据**完全不变**（copy-on-write 的核心不变量：
     未 commit 就崩溃不能出现半个文件）。
4. 原"写入后强制终止"用例加逐条抽查（0/1/24/25/49）—— 只断言计数会被
   "重复主键覆盖后计数恰好相等"蒙对。
5. CI 注释改为准确描述实际覆盖的窗口，并点明 e2e 依赖 dist/ 产物。

验证：14 项 e2e 全绿（8.9s，真实 Chromium + 真实 OPFS）；
jest 全量 85 套件 / 1665 测试通过。

.gitea/workflows/ci.yml

@@ -101,6 +101,11 @@ jobs:
         run: npm run build
       - name: Verify Playwright browsers
         run: npx playwright install chromium
-      # v0.8.0: e2e 覆盖真实崩溃注入（CDP Page.crash）与真实 OPFS 语义
+      # v0.8.0（PC-2）: e2e 用 CDP `Page.crash` **真崩溃**注入，覆盖三类窗口：
+      #   ① 写入进行中崩溃（不等 Promise）② OPFS createWritable 的 write 阶段
+      #   ③ 提交（close/原子替换）阶段；另含 checkpoint 前后、KVStore WAL 半写、
+      #   多标签页锁、加密往返、页面化 + 二级索引、repair 自愈。
+      # 注意：e2e 依赖 dist/ 产物（harness.html 加载 /dist/metona-sqlark.js），
+      # 因此上面的 Build 步骤是必需的；主 job 会校验 dist 与源码同步。
       - name: Run E2E tests
         run: npm run test:e2e