chore(docs): 删除 v0.7.4 审计与 v0.7.5 计划共 4 个 md 文档

删除：
- AUDIT-aria-lsm-v0.7.4.md（50KB）
- AUDIT-query-layer-v0.7.4.md（39KB）
- AUDIT-storage-engines-v0.7.4.md（39KB）
- PLAN-v0.7.5.md（98KB，含附录 G/H/I）

删除前先清除引用面，避免留下断链（共 18 处）：
- 源码注释 7 处（change-notifier / kvstore index / column-value / expression /
  sql-compare / where-matcher / validation）：保留设计意图，引用改为"v0.8.0 审计根因 N"
- 测试注释 9 处（opfs.spec / aria-opfs-backend / faulty-backend / storage-harness /
  v080-b6 / v080-kvstore / v080-query-layer / v080-sql-three-valued /
  v080-unified-validation / parser）：同上
- CHANGELOG 3 处：改为不依赖已删除文档的自洽表述（B-6 交付物见各条；门禁订正三处
  按内容重写），并把变异数量同步为 42
- 校验：三个 md 之间无断链；仓库内已无 PLAN-v0.7.5/AUDIT-* 的任何引用
  （git 历史仍可追溯，需要时可 `git show <commit>:PLAN-v0.7.5.md` 找回）

验证：93 套件 / 1985 用例全绿；覆盖率 90.59 / 82.61 / 94.14 / 93.50（阈值 90/82/94/93）；
e2e 14/14；lint + 两份 tsc 干净；dist 已重建（注释只影响非压缩产物，min 产物
251,731 B / gzip 63,431 B 不变）。

说明：审查记录的核心内容仍在 CHANGELOG.md（"全量回归审查"与"现场失败修复"两节），
随 PLAN 一起删除的是附录 G/H/I 的详细表格（门禁逐条验收、交付物清单、未修复项表）。

tests/e2e/opfs.spec.ts

@@ -36,7 +36,7 @@ async function run<T>(page: Page, method: string, args: unknown = null): Promise
  *
  * 修复前这里只是 `win.__ms = null; await page.close()` —— 那是**优雅关闭**：
  * 没有未完成的 I/O、不经过任何崩溃窗口，因此"崩溃恢复"的结论实际上是在
- * "正常关闭后重开"上得到的（PLAN-v0.7.5.md 根因 5：崩溃语义声称未被验证）。
+ * "正常关闭后重开"上得到的（v0.8.0 审计根因 5：崩溃语义声称未被验证）。
  *
  * 现在用 CDP `Page.crash` 直接终止渲染进程：进行中的 OPFS 写入、未 flush 的
  * WAL 缓冲、同步访问句柄全部**立即**消失，与浏览器/标签页被强杀一致。

tests/engine/aria-opfs-backend.test.ts

@@ -14,7 +14,7 @@
 // ===================================================================
 //  v0.8.0: 删除本文件内的第三份 OPFS mock —— 改用共享的 storage-harness。
 //
-//  原实现的问题（见 PLAN-v0.7.5.md 工作流 C-1）：
+//  原实现的问题（见 v0.8.0 迭代工作流 C-1）：
 //   - 与 tests/helpers/opfs-mock.ts 重复（两份都在测同一件事，语义各自漂移）；
 //   - `close()` 是空函数、写入立即可见 → 无法表达"提交前崩溃"；
 //   - 定义了 `writeCalls` 记录但**从未被任何断言使用**（死代码）；

tests/helpers/faulty-backend.ts

@@ -2,7 +2,7 @@
  * 测试共享 — 故障注入后端包装器（v0.8.0 工作流 C-1）
  *
  * ============================================================================
- * 为什么需要它（PLAN-v0.7.5.md 根因 5）
+ * 为什么需要它（v0.8.0 审计根因 5）
  * ============================================================================
  * 项目所有"崩溃恢复"测试用的都是 `await engine.backend.close()`，而 OPFSBackend.close()
  * 会 `await this.writeQueue` 把在途写**全部刷完** —— 那是优雅停机，不是崩溃。

tests/helpers/storage-harness.ts

@@ -2,7 +2,7 @@
  * 测试共享 — OPFS 事务性文件存储（v0.8.0 根治版）
  *
  * ============================================================================
- * 为什么需要重写（审计结论，见 PLAN-v0.7.5.md 工作流 C-1）
+ * 为什么需要重写（审计结论，见 v0.8.0 迭代工作流 C-1）
  * ============================================================================
  * 旧 mock（tests/helpers/opfs-mock.ts）有三处与真实 OPFS 语义不符，会掩盖真实缺陷：
  *   1. `read()` 返回内部 ArrayBuffer **引用**（真实 OPFS 返回快照副本）

tests/sql/parser.test.ts

@@ -3,7 +3,7 @@
  *
  * v0.8.0 强化说明：
  *  1. 此前 12 处断言写着 `expect(ast.where).toBeDefined()` —— 既没有验证结构也没有验证
- *     值，属于"空断言"。审计（AUDIT-query-layer / SQL 层）指出：`parser.test.ts` 无一处
+ *     值，属于"空断言"。审计（v0.8.0 · query 层）指出：`parser.test.ts` 无一处
  *     断言混合 AND/OR 的**结构**，这正是 AND/OR 无优先级缺陷（总账第 11 项）能长期存活的原因。
  *  2. 本文件此前 `parse()` 的返回类型是联合类型 `Statement`，直接访问 `.where` / `.columns`
  *     在类型上不成立（tests 从不做类型检查，所以没人发现）。现在用类型收窄辅助函数显式

tests/v080-b6-single-commit-point.test.ts

@@ -1,7 +1,7 @@
 /**
  * v0.8.0（B-6）回归套件 —— 存储层**单一提交点**（`__aria_manifest`）与 LSM 结构根治
  * ============================================================================
- * 本套件覆盖 PLAN-v0.7.5.md 工作流 B 的 B-6 全部条目。每一条都对应一个**实测过**
+ * 本套件覆盖 v0.8.0 迭代工作流 B 的 B-6 全部条目。每一条都对应一个**实测过**
  * 的缺陷（或一条被写进 manifest 的持久不变量）：
  *
  * | 编号 | 缺陷 / 不变量 | 本文件对应用例 |

tests/v080-kvstore-commit-point.test.ts

@@ -1,7 +1,7 @@
 /**
  * v0.8.0 回归套件 —— B-6 存储提交点与崩溃语义（KVStore）
  * ============================================================================
- * 本套件覆盖 PLAN-v0.7.5.md §4「B-6」列出的 KVStore 三处止血，其中两处是
+ * 本套件覆盖 v0.8.0 迭代 §4「B-6」列出的 KVStore 三处止血，其中两处是
  * **P0 级数据丢失**：
  *
  * 1. `open()` 遇到损坏日志尾部会**清空整个日志**（`truncateLog()` 写空文件）。

tests/v080-query-layer.test.ts

@@ -1,7 +1,7 @@
 /**
  * v0.8.0 回归套件 —— 查询层缺陷根治（A22/A23/A25/A26/A27/A29/A30/A36）
  * ============================================================================
- * 本套件锁定 PLAN-v0.7.5.md §5 缺陷总账中查询层的 8 项修复。每一项都先给出
+ * 本套件锁定 v0.8.0 迭代 §5 缺陷总账中查询层的 8 项修复。每一项都先给出
  * **修复前的实测错误输出**，再断言正确结果 —— 这样即使将来重构执行器，
  * 失败的断言能直接告诉后来者"当初错在哪里"。
  *

tests/v080-sql-three-valued.test.ts

@@ -1,7 +1,7 @@
 /**
  * v0.8.0 回归套件：SQL 三值逻辑（NULL 语义）—— PB-2
  * ============================================================================
- * 本套件锁定 PLAN-v0.7.5.md 根因 7（"未解析/UNKNOWN 静默变 false"）与
+ * 本套件锁定 v0.8.0 审计根因 7（"未解析/UNKNOWN 静默变 false"）与
  * 附录 §5 缺陷 A15 的修复契约，并对**四种存储引擎**逐一验证同一语义。
  *
  * 历史缺陷（本套件即为其反例）：

tests/v080-unified-validation.test.ts

@@ -1,7 +1,7 @@
 /**
  * v0.8.0 回归套件 —— B-1 统一行校验（工作流 B 第 1 项）
  * ============================================================================
- * 背景（PLAN-v0.7.5.md 根因 1 + 缺陷 A12/A17）：
+ * 背景（v0.8.0 审计根因 1 + 缺陷 A12/A17）：
  * 修复前存在**三份**行校验实现，覆盖面各不相同 —— Memory/KVStore/Hybrid 共用
  * 一份"只查类型"的实现（**没有** maxLength/min/max），Aria 走 checkFieldType
  * （有约束），schema.ts 是第三份。于是：